9
6 Comments

Are you making meaningful improvements or flashy ones?

You have a 2-step process. You have a choice to reduce:
A) Step 1 from 5 mins to 5 seconds
OR
B) Step 2 from 15 mins to 14 mins. What's your choice?

Of course, the first! Ermm, nope, let's discuss :)

Typically, most of our processes are continuous. For e.g., take the tech world. You have a designer (Step 1) and a developer (Step 2). They work continuously to deliver new features. The time a certain feature takes is Time of Step 1 + Time of Step 2.

But, here's the clincher. The time taken to deliver the next new feature is just the time of the slower process. Why? Because after the designer finishes Feature2, it just sits on the developer's desk, while the latter is still working on Feature1.

Let's look at numbers:
Scenario A: Step 1 reduces to 5 seconds . Step 2 still takes 15 mins
If we choose Option A), the total time of a certain feature reduces from 20 mins to 15 mins & 5 secs. However, the time to deliver the next feature is still 15 mins. Your customer doesn't receive the next feature any earlier.

Scenario B: Step 2 reduces from 15 mins to 14 mins . Step 1 still takes 5 mins
If we choose Option B), the total time of a certain feature only reduces to 19 mins from 20 mins. However, the time taken to deliver the next feature decreases to 14 mins. Your features to your customer will reach a minute sooner!

Does your answer change now?

This might seem obvious but we are often working on improvements, judging them independently rather than thinking of the end impact they have. Have you faced this problem? Do let me know :)

Takeaway: Look at bottlenecks. Solving them has benefits. Rest are just flashy improvements.

on June 19, 2020
  1. 1

    This comment was deleted 4 years ago

    1. 1

      The developer/designer example is just illustrative. It can be applied across contexts. Also, even in this example, it is assumed that they work concurrently just not for the "first feature" - again it is just illustrative. Anyway, in essence, a designer's role precedes that of a developer at the beginning of any product and then they start working collaboratively.

      On an aside, I don't know what a "real product team" is, but I've built many products, playing the role of a developer/designer/product manager as needed.

  2. 1

    This comment was deleted 6 years ago

    1. 1

      But, here's the clincher. The time taken to deliver the next new feature is just the time of the slower process. Why? Because after the designer finishes Feature2, it just sits on the developer's desk, while the latter is still working on Feature1.

      The time taken by a single feature will be 19 mins, but the time taken between the delivery of two features will be 14 mins.

      Let me try to illustrate it further:
      T=0
      Designer starts feature 1

      T=5
      Designer finishes feature 1 and starts on feature 2. Developer starts on feature 1

      T= 19
      Developer delivers feature 1 and can start on feature 2 (already completed by the designer at T=10)

      T = 33
      Feature 2 is completed and delivered.

      So the total time taken by feature 2 is still 19 mins but the time between feature 1 and feature 2 is 14 mins. It would be 14 mins for the time between any subsequent features.

      I hope I have explained it clearly now.

      1. 1

        I think I get. The first feature would be quicker, but after that the completed work from the first stage is just queued up and features only complete at the rate of the slower second stage.

        1. 1

          That's exactly it! It is a typical bottleneck concept.

          The idea is to analyze your setup to understand which part of it is causing the maximum pain (the bottleneck) and then trying to improve that.

          Instead, often what we do is to work on the part of the setup that we can improve the most, which will not make any impact.

      2. 1

        This comment was deleted 6 years ago

        1. 1

          I said there are two choices that could be made: either decreasing step 1 from 5 mins to 5 secs OR step two from 15 mins to 14 mins.

          I doubt this is contrived because I shared it with many people. But I understand that I could have formatted things better. I have tried it once more, maybe you could take a look.

          Anyway, the idea was to drive the point in a better way by using numbers. But my takeaway isn't meant to be theoretical but something that I feel even I am guilty of doing and should correct, which is: to solve for bottlenecks and not randomly any area that can be improved the most.

          1. 1

            This comment was deleted 6 years ago

            1. 1

              Great. Oh cool - I thought it was obvious that a developer and a designer would always work in parallel and not wait for one another.