Developer's career, do most of them just vanish without any meaningful work?

Sometimes I felt that kind of anxiety. 'If I keep going like this, won't my developer career end without much meaning?'

Of course, the reason seems to be that we only see the ideals of Uber, Airbnb, Google, Facebook, Paypal, Youtube, LinkedIn, etc. and cannot see the reality. In reality, only 5 out of 1,000 apps are successful [1], and 30-day retention is a statistic of 5%.

Statistics say most fail. Then I found a book that discussed 'Why most people fail and how to fail faster and get feedback at less cost.'

This is the book 'The Right It' by Alberto Savoia [3], who was an engineer at Google and served as an Innovation Agitator.

How to find the right thing according to 'The Right It'

The argument of the book can be summarized as follows:

1. Most failures are Market Failures (i.e., failure to find PMF)
2. The reason is that rather than doing the right thing, we do something incorrect based on our brain's assumption (it is the right thing to do, but we only think about it with our brain, so we tend to ignore actually good ideas).
3. That's why it's important to break away from the brain's formality with data. At this time, the data must be correct (recent, relevant, reliable, meaningful, and therefore directly obtained data).
4. In order to obtain this correct data, the user engagement hypothesis (Member Engagement Hypothesis) must be replaced with a numerical value that can be tested to enable experimentation (pre-totyping) at low cost.
5. This experiment can help you discover the right thing to do for less

The core of the five procedures above is an experiment that can secure the data necessary for judgment at a low cost. In the book, it is called pretotype, which is before prototype.

If you look at the IBM example below, you will understand exactly what pretotype means.

Pretotype

A few decades ago, IBM had a great idea - 'It's difficult for most users to get used to typing, so why not develop and release a speech-to-text feature?'

At a time when the perception of PCs was very different from what it is now, IBM, which was struggling, began to seriously consider development. At the time, speech-to-text technology was high-tech and could be developed at a great cost.

Unsure of the usability of the feature in practice, IBM asked the following questions: 'How can I get the data to decide if this is the right thing to do at a low cost before making a large investment?'

In other words, I was thinking about the pretotyping method.

Then IBM came up with a good idea. An experiment was conducted to make a fake Speech-to-text appear real to the experimental group (users), and when the experimental group spoke into a microphone, a hidden stenographer quickly transcribed it so that it felt like a 'real working' Speech-to-text.

And within a few hours of conducting such an experiment, IBM's brainstorm collapsed. First, the experimental group started to feel hoarse after using it. Also, because everyone was talking to the computer to input data, it became noisy or interfered with each other. And it became impossible to write a secret email like, 'Let's exclude Bob from this promotion.'

Through this low-cost pretotyping, IBM was able to collect data on products that would have taken years of time and tens or hundreds of development resources to determine success or failure, and prevented them from developing in the wrong direction.

Thoughts & Steps for the Right It

After reading this, I think that the key to product development is how good you are at prototyping. So, I think I'm getting a bit of a sense of 'By what criteria should I choose where I want to be in order to be able to experience meaningful products?'

• An organization that ‘speaks in numbers’ based on proper data
• An organization with an established ‘experimental culture’ of establishing hypotheses, conducting prototypes, and verifying them.

Lastly, I share the practical action plan from the original text:

1. Start with an idea
2. Identify the Market Engagement Hypothesis
3. Turn the MEH into a say-it-with-numbers XTZ Hypothesis
4. Hypozoom into a set of smaller, easier to test xyz hypotheses
5. Use pretotyping techniques to run experiments and collect YODA (Your Own DAta)
6. Use the TRI(The Right It) Meter with the Skin-in-the-Game Caliper to help you analyze the YODA
7. Decide on the next step: a. Go for it! You can't be 100% sure that your idea is The Right It, but the YODA looks promising enough for you to take a calculated risk b. Drop it. As much as you'd like your idea to succeed, the YODA stubbornly indicates otherwise c. Tweak it. In the process of testing your idea, you have learned invaluable things about your target market and its willingness (or unwillingness) to engage with your product. Don't hesitate to tweak your original idea (or your hypotheses) to reflect what you've learned along the way. You may find that although there is not enough market interest in your original idea, there may be great interest in something related to it. Or try flipping the idea on its head and see what you come up with

Reference

[1] https://www.fyresite.com/how-many-apps-fail

[2] https://sendbird.com/blog/app-retention-benchmarks-broken-down-by-industry

[3] https://www.albertosavoia.com/about.html