First, let us admit that there is no perfect decision in real life. If we know this, why do we pursue it even when it is not worth it and costing us? This of course works in product management and entrepreneurship especially for digital innovation products. When it comes to how to think about the importance of decision we have to think against the other main dimension, time. As you read, this is structured starting a simple case and then adding a layer of complexity to it and seeing how this complexity affects our time and our decision, spoiler alert, it shouldn’t.
For our case we have a decision between how to order two items of work in our backlog and importance, let us consider them features. We have to have some assumptions: first, there is only a single team, second, We know the value curve for them is the same and it is flat for the near future.
Feature
Time in weeks
Value per week
A
3
5
B
1
2
The charts bellow will show the value over time, and the waste explains areas where there is no value compared to maximum possible value.
Option 1: work on them at the same time, there will be inefficiency when it comes to task switching, but let us ignore that for now and assume no cost of task switching. This means we will launch the features and getting value after 4 weeks of work. After 6 weeks the total value would be (14)
Option 2: work on A first. Total value after 6 weeks is (19)
Option 3: work on B first, total value after 6 weeks is (20)
Based on mapping our options, the first conclusion is to work on the feature with the highest value/time factor.
Feature
Time in weeks
Value per week
Value/time
A
3
5
5/3 = 1.66
B
1
2
2/1 = 2
The second conclusion, do not create unneeded dependency between value generating items, which is the case when launching them together.
Now let us add the layer of complexity. Let us assume the same features above in the previous example, but there is some uncertainty in value generated. This uncertainty needs a week to resolve. And to simplify, let us assume that this probability is 50% for each value for each feature.
Feature
Time in weeks
Value per week
A
3
(4-5)
B
1
(1-2)
So the options are to wait or not, and which feature to start with, A or B. We will end up with 16 probabilities.
Waiting
Order
A value
B value
Value at week 1
2
3
4
5
6
Total Value
No wait
A first
5
2
0
0
0
5
7
7
19
No wait
A first
4
2
0
0
0
4
6
6
16
No wait
A first
5
1
0
0
0
5
6
6
17
No wait
A first
4
1
0
0
0
4
5
5
14
No wait
B first
5
2
0
2
2
2
7
7
20
No wait
B first
5
1
0
1
1
1
6
6
15
No wait
B first
4
2
0
2
2
2
6
6
18
No wait
B first
4
1
0
1
1
1
5
5
13
Wait
A first
5
2
0
0
0
0
5
7
12
Wait
A first
4
2
0
0
0
0
4
6
10
Wait
A first
5
1
0
0
0
0
5
6
11
Wait
A first
4
1
0
0
0
0
4
5
9
Wait
B first
5
2
0
0
2
2
2
7
13
Wait
B first
5
1
0
0
1
1
1
6
9
Wait
B first
4
2
0
0
2
2
2
6
12
Wait
B first
4
1
0
0
1
1
1
5
8
With this, we see that our best case if we wait will be as good as our worst case scenario if we don’t wait. Then why wait?  No matter how you look at the case, this example above is very simple and theoretical. The number of variables in the decision making is too large and we cannot take them all into account.  To understand the range of assumptions that we did to simplify the case I am mentioning some:
  1. The cost of work: in the case the value we created was created without any cost, when in fact, any value creation will take time and cost, such as salaries or other resources.
  2. Late to market: The features didn’t take into account competition or market opportunity. One might have a great feature for a Zeppelin to fly at double the speed with a slight increase in cost, but market conditions are long past for this feature.
  3. Value curve: some features might create value for a longer term than other features that are short term in nature.
  4. Ability to measure the value accurately: What amount of value a feature brought of a complete product is usually pretty difficult to calculate even in retrospect. Value can be subjective as well such as brand awareness or risk mitigation.
  5. The probability of success: we assumed that our features will create value, which means the market wants them and there is demand. Even immediate.
  6. Features work predictability: the features are assumed to be doable, which might not be the case and requires testing and investigation. They are assumed to be clear and we know how to do them.
  7. Small wins: small wins might be needed for the team, product or company to gain momentum.
  8. Team performance stage: if the team is newly formed, one might want to avoid trying to create the most difficult features until the team passes the storming stage.
  9. Feature dependency: There might be dependencies between features, something more technical or based on market conditions.
  10. Decision making Bias: there are many human biases when taking a decision and it affects how rationally we approach the decision making process.
Is this too much to think about? Of course it is, however, this is why making these decision can be really hard, but it doesn’t have to be. Here are a few recommendations to keeping decision making under control:

Good and quick rather than perfect and late

Time box the decision making, since the scope (decision completeness) is flexible, make time fixed. This will require accepting that mistakes and bad decisions will be made. Avoid when it comes to ethical issues, it is worth spending time on it then. What is a good time frame for a decision? It depends. Some teams decide to do the work as per the previous decision or as per the current backlog. It is a learning process but we are usually slow, so think about increasing the speed of your decisions now.

Listening to stakeholders

Decisions doesn’t have to be a one man show. You can collect as much feedback from stakeholders as needed, by interactions or by experimentation, and then make the decision.

Building the frameworks to collect and analyze information quickly

  • Priority matrix: A good subjective framework to think about that can help with 80% of decisions is to prioritize impact vs urgency. Like any tool, this can be misused. Having challenges with using it can help diagnose issues as well. For example: If you plot all your features or projects and realize it is difficult for you to determine the impact then your vision is not helping in defining the impact. If everything seems urgent then nothing is – there is no clear definition of what urgent means.
  • Listening to others: “Leaders who don’t listen will eventually be surrounded by people who have nothing to say.” Andy Stanley. Feedback can come from the team, for example listening to sales about clients and listening to developers about the product challenges. Synthesizing this information is what can create a better decision, even if these pieces of information can seem contradictory.
  • Gathering information quickly: digitization and experimentation rich environment should be the focus instead of trying to theoretically create the best feature with perfect decision. A word of caution: Data can tell a different story that reality because in the end, we are collecting it and interpreting it based on our misconceived notions.
    On By admin

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    s