02 Starting with the End: How to Make Your Efforts Worthwhile? #

Hello, I’m Zheng Ye.

To start today’s content, I want you to first ponder a question: If you were to design a login feature, how would you do it?

I once conducted an exercise within the company where I played the role of the client, and I asked everyone to help me design a login feature. My colleagues were thrilled upon hearing this. “Login is just a combination of username and password, right? I’m familiar with it. I can even design features like captcha, password recovery, and third-party login.”

Some of my more proactive colleagues had already begun designing database tables and considering using Redis for caching. Throughout the entire process, everyone discussed enthusiastically, with the only person being ignored being myself, the “client”.

After the discussion concluded, I, in the role of the client, told everyone that as a “tycoon”, I intended to create a ride-hailing app where users can log in by receiving a verification code via their mobile phones. You can imagine the expressions of my colleagues, who felt “tricked”. Indeed, their design of a username and password login was completely off-topic.

Though this was a simple exercise, it reflected a real-life work scenario that we often encounter: many people start brainstorming everything right after hearing someone’s request for a feature. The result is that the efforts made become meaningless.

So where does the problem lie? It’s because we lack the habit of starting with the end in mind.

A Counterintuitive Way of Thinking #

To start at the end is to think about what the outcome will be before doing something.

It sounds simple, but it’s not easy to do. The thinking pattern we are accustomed to is linear and sequential – do the first step, then the second step; finish the second step, then do the third step.

This is understandable. We humans have evolved from ancient times, in an era where food was scarce. Thinking in reverse was not very useful back then, and people weren’t even sure if they would see the sun tomorrow. Centuries of evolution have left us with many short-sighted behaviors and thinking habits because this approach is the most energy-efficient, and looking into the future requires extra energy.

“To start at the end” is a counterintuitive way of thinking that most people do not possess. Therefore, in our daily lives, we see many interesting phenomena.

For example, when graduating from university, many people want to take the postgraduate entrance examination. If you ask them why they want to do so, the usual answer is to find a good job. But does taking the postgraduate exam really help them find a good job? Not necessarily because finding a job and taking the postgraduate exam are not on the same skill tree.

If you really want to find a good job, you should understand what the job requirements are and how to acquire the skills needed for the job.

Looking at it from this perspective, you will find that the postgraduate entrance exam is just one of the many paths to get to a good job. For example, you should find an internship to develop your professional skills. This is the way of thinking with “starting at the end.”

Returning to the earlier example of “designing a login function,” compared to the “starting at the end” thinking, you might feel sorry for my colleagues. Perhaps they also have the mindset of “starting at the end,” but their “end” is different from that of the client. This brings us to the essence of software development, which is essentially building a “collective imagination”.

The Imagined Community #

If you have read Yuval Noah Harari’s “Sapiens: A Brief History of Humankind” or “Homo Deus: A Brief History of Tomorrow,” there is a concept that you are probably familiar with: the imagined community. The author believes that a significant factor in the development of human history is the “collective imagination,” whether it is nation-states, religions, laws, or customs – they are all “collective imaginations” that people have agreed upon. Humanity is a community that identifies itself with these “collective imaginations.”

Those of us who work in software development are actually an imagined community, and this “collective imagination” is the software we create. Any imagination requires a medium to be realized, and the process of writing software is the process of implementing this “collective imagination.”

Since it is a “collective imagination,” it is difficult for our imagination to come together before it is presented by a medium, and there are bound to be differences to some extent.

Therefore, anything needs to go through two acts of creation: one in the mind, which is the mental or first creation, and then it is put into practice, which is the physical or second creation.

Many of the problems we encounter in our work actually arise from not doing the first creation well and jumping straight into the second creation. Therefore, we often encounter “surprises” in our work, or more accurately, shocks.

Compared to the first creation, the second creation is a very costly process. We know that software development is time-consuming and labor-intensive. Once a significant amount of effort is invested and it is discovered to be greatly deviated from the understanding, everyone will feel helpless.

Therefore, before starting work, we need to put more effort into the first creation, to align the “collective imagination” of all relevant parties. Taking architecture as an example, it is about conceptualizing various details on the blueprints. In software development, we can do many things, such as:

• To show users what the product looks like, we can use prototyping tools to create it, instead of having to fully develop all the features.
• To present the appearance of a service interface, we can set up a simulated server to provide the service, without having to wait for the backend to be fully developed.
• To let programmers know the details of the product they need to develop, software scenarios and behaviors can be described in the tasks.

Going back to the example of “designing a login feature,” my colleagues were actually constructing their own imagination, not our shared imagination. The biggest difference here is that no one will pay for their own imagination.

Therefore, what they see as the “end” is not the true end, but rather a self-centered “end.” As for what kind of “end” they see, it depends on each person’s insight.

For those who work in software development, we should position the “end” as creating software that brings value to the users, so that our own value can be realized.

With this preliminary understanding of “beginning with the end in mind,” how can we apply this mindset in our work?

Planning and Discovery #

The software industry is full of heroic legends, where an individual or a team works continuously for a period of time, writes a software program, and discovers a problem on the eve of launch. They then take the risk of staying up all night to solve the problem and become famous through their success.

These stories are exciting to hear, but upon closer examination, why do problems always seem to be discovered at the last minute? Apart from the pressure of time, in most cases, they simply did not plan properly before starting.

Within a team, I have always advocated for starting with the end in mind and having everyone think backwards before starting to plan. This way, the planned work can align more precisely with the actual goals. Let me give you an example from a previous product development experience. When we were starting our business, we planned to create an Internet of Things (IoT) development platform, but what exactly should it look like?

With the “starting with the end in mind” mindset, we considered how others would use our platform. Our design approach was for users to visit our website, read the relevant documentation, and then follow the instructions step by step.

One key point in this process is documentation, especially the “Getting Started” guide. This is the first step for users to interact with our platform and sets their initial impression of our product.

So, we decided to start by writing this “Getting Started” document. This document outlined how users could use our development platform step by step to create their first “Hello World” level application. Please note that at this point, we haven’t written a single line of code.

With this “Getting Started” document completed, everyone on the team already had a preliminary understanding of what our platform should become. Most importantly, we could take this document and discuss our yet-to-be-born platform with external stakeholders.

Humans are good at imagining things, and once someone sees this document, they can already envision what the platform will look like and provide various feedback: “I think this part can be done this way” or “I think that part can be improved”.

All this feedback is real because they have already “seen” something tangible. It is through this real feedback that we gradually solidify our goals. Only then do we start writing code.

The “starting with the end in mind” approach not only helps us plan our work, but also helps us discover issues in our work.

Once, my team was developing a major feature to transform our existing system into a multi-tenant system. This meant that other vendors could apply to use our platform and have the same capabilities as our existing platform.

Tasks were assigned, and everyone went to work on their respective tasks. However, I had a nagging feeling of unease and kept worrying that something might be missing. So, I urged the project manager to outline the deployment process.

Yes, the deployment process. Although our code wasn’t fully developed yet, with the mindset of “starting with the end in mind,” we assumed that each component had already been developed and started thinking about how the deployment should be done.

Sure enough, as we outlined the deployment process, we discovered a problem: how to identify different tenants? Someone suggested using an HTTP header, but who would set this HTTP header? Nobody had thought about it in detail. And so, a potential issue was discovered, at least saving us from working overtime in the future. As programmers, we always find ways to solve problems.

In fact, the principle of “starting with the end in mind” has been applied in many software development practices today.

For example, Test-Driven Development (TDD). What is testing? It is the “end” of your code, and only after passing the tests can we say that the code is complete. Of course, TDD involves more than simply writing tests first.

Another example is continuous integration. We are delivering a runnable software, and when we think backwards, the best approach is to keep the software in a runnable state continuously, hence the need for continuous integration.

In summary, practicing “starting with the end in mind” means considering the results before starting and determining what needs to be done based on those results.

This is the introduction to the “starting with the end in mind” concept. In the following sections, I will introduce its applications in different scenarios and analyze some best practices from the industry. I believe this will be helpful for your actual work.

Summary #

For a while, there was a post circulating online about how Amazon CTO develops a product. In short, they use a backward approach, with the sequence of developing a product being:

1. Write a press release.
2. Write FAQs (Frequently Asked Questions).
3. Write user documentation.
4. Write code.

Today, I have introduced you to the concept of “starting with the end in mind.” Looking back at this post, I believe it’s not difficult for you to understand why Amazon does things this way.

People are accustomed to thinking in a sequential manner, and thousands of years of evolution have ingrained this thinking pattern in our genes. To become a better version of ourselves, we need to overcome our own limitations. And the way to do that is simple: “start with the end in mind,” reverse your thinking, and consider the results first.

Humanity is an imaginative community, and a software development team even more so. The software we create is the medium through which we bring our “collective imagination” to life.

Everything goes through two creations: a mental or first creation that happens in our minds and an actual or second creation that takes place in reality. We should put more effort into the first creation, unify our collective imagination, and make the goals more clear.

The “starting with the end in mind” mindset can help us better plan our tasks at hand and also help us identify problems along the way.

If there’s only one thing you can remember from today’s content, please remember: when faced with something, think backwards.

Finally, I would like you to reflect on whether you have applied the “starting with the end in mind” approach in your work or life. What problems has it helped you solve? Feel free to share your thoughts in the comments section.

Thank you for reading, and if you found this article helpful, please feel free to share it with your friends.