Recently, I came across two tweets 1, 2
@NalaGinrut: Let me share a bit of experience with you all, anything serious (or what's so-called getting into it) is boring. When someone tells you what they're doing is extremely pleasurable, they're still on the surface.
@zhangjintao9020: The first part is basically true. As for the second part, people find joy/fulfillment in different things, even if it's boring, it doesn't stop you from finding happiness (the scenery along the journey is also nice).
From my own experience, this is indeed the case.
When I was younger, I studied fine arts, specifically Chinese painting. At the beginning of a new painting, the first half is always the most exciting. Sketching outlines, adjusting poses, arranging the composition, deciding on color tones and mood, etc., these are all elements that can affect the whole piece.
But as it gets to the latter half, such as detailing or correcting errors from the first half, it doesn't feel as thrilling anymore. Patience wears thin, and hands aren't as nimble. However, if you really think about it, it's these tedious tasks in the latter half that determine whether a piece can touch the audience in detail. That's what my teacher used to tell me.
Later, as a software engineer, I also fell into the common pitfall of programmers: after being in the field for a while, accumulating a bunch of prototype projects became a routine:
- Suddenly feeling inspired, start a new project.
- Realize a component in the project should be standalone.
- Put the project on hold, begin developing this component.
- Realize the component lacks generality, start covering more use cases (even if your project only needed one).
- The project progresses very slowly, starting to slack, so decide to play games or watch TV.
- After some time, lose interest in the project.
And then, as you go on, it becomes less appealing to continue.
Why Prototyping Excites
There's something thrilling about putting together a project prototype. One reason is that prototypes can quickly receive feedback, bringing immense joy.
In software engineering, creating a prototype system takes very little time.
This is because all prototype systems start from a day's "I reckon," aiming to demonstrate a new technology's principle or test out the feel of a new idea.
Moreover, prototype solutions are usually built in isolation. The system's implementation only meets a tiny requirement, separated from the real-world demands and users. That is, these prototypes don't need to be accountable to any real needs and users, allowing them to ignore future expansion troubles and just satisfy the immediate minimal requirement.
Therefore, from "I reckon" to the first run of the project, it indeed takes a very short time, typical "I reckon" scenarios like Hackathons often just need one night. This way, developers can quickly enjoy the pleasure from "I reckon" to "wah."
But formal products are different. Turning it into a product requires a lot of time and effort.
Another reason I think is that people are more easily caught up in the hype of new technologies and concepts than in laying out a prudent roadmap.
This is especially evident in the operations of a business.
For example, "machine learning" seven years ago, "blockchain" three years ago, "AI" three months ago, and the current VR/AR. You see in the news that a big company is ready to "ALL IN" a certain field—but in reality, it might just be that in some office, the company's leaders listened to a half-hour podcast and then decided on this "ALL IN"; or that an employee quickly validated a new technology concept through a prototype and reported it from the bottom up to the higher-ups: why this technology could change industry rules, and then "ALL IN."
No matter how it started, everyone would eagerly begin building prototype systems, which has many benefits:
- In this initial stage, fast is good. So there's no need for any investigation or research required by a production system.
- It brings quick internal success, allowing everyone to promptly celebrate the company's innovative culture, with genuine applause from all.
- For employees
, it's an interesting and exciting "exercise." Compared to daily work, it's a good distraction.
Then, as the excitement gradually fades, the project stalls. What to do?
Prototypes Aren't Enough
Looking back, I agree with the viewpoint of the tweets at the beginning of the article: many things, once you get into them, are boring—at least the boring parts will occupy a large and fixed portion for a long time.
For example, Quail.ink, which I use to publish articles now. I decided to write a newsletter on April 18, and then the first version was online four days later. But the actual launch date was July 7, more than 2 months after the first version was online.
Of course, it was very imperfect at the beginning. Even now, Quail's Todo List is still very long, with much work to do and many problems to solve.
Some of this work was planned from the beginning. For example, payment for content purchases, binding custom domain names, data import and export, etc.
Many others were unexpected:
- Some are new problems and bugs that need to be solved. For example, a deadlock issue that occurred recently, causing a process to not work properly, which needs to be checked and fixed.
- Some were parts not considered in the previous planning. For example, regarding custom domain names, it was initially intended to use Cloudflare's TLS for SaaS, but later found to be unsuitable. Therefore, plans needed to change, using ACME to add Let's Encrypted certificates for each bound domain name. This created additional workload.
- There's also a significant amount of transactional work, unrelated to specific feature development. For example, in the past two months, as traffic increased, the previously unimplemented load balancing needed to be done -> after implementing load balancing, the previous single-machine cache needed to be switched to Redis... Such work, though imperceptible to users, is essential.
Many of these tasks, especially the last type — very boring — often don't want to do internally but have to — because this is the price that must be paid for stable service and continuous iteration.
And that's just the engineering part.
As a product manager, you also have to consider what to do and what not to do in the future. All those non-engineering thoughts and decisions, including "what level the backend editor should reach," "how much AI should be integrated," such design requirements, and "what matters to core users like authors," such long-term issues, need to be considered.
Making It Less Boring
Knowing the reasons for being boring gives us a chance to keep the project going:
Declare It Early
The "build in public" approach adopted by many independent developers does just that: let everyone know what you're doing as early as possible.
On one hand, you can get firsthand feedback; on the other hand — and this is very important — people will encourage you to keep going.
I had a project called Hotot. Initially, I just wanted to play around, but suddenly it was reported by a Spanish Linux media, and the user base grew overnight. I was happy to continue working on it until Twitter changed their API policy.
Confirm the Need Exists
For many engineers, this might be difficult. Both macroscopically, "is this worth doing," and microscopically, "is this user experience good," are closely related to understanding users and the market.
Besides self-learning to become a product manager, there's a simpler method: only focus on the needs of the group of people you represent.
Understanding yourself is definitely easier than understanding others. If you're very satisfied with what you've done, it means there's a potential group of people similar to you who would also be satisfied. Once this direction is determined, just meet the needs of this group of people you represent to the fullest.
Choose What to Do and What Not to Do
Tinkering with anything is an investment. Writing code, designing takes time and energy, and servers cost money. So since it's an "investment," the rationality of the investment, i.e., the return, must be considered.
If I plan to create a new app or service, I need to prove this "investment" is reasonable. If this new prototype product can only bring nominal incremental value and there's no direct economic return, it's necessary to determine what it can actually bring us.
Of course, not all prototype products must generate economic income; they may also be created to validate concepts or explore new fields. The goals of these projects might be to gather user feedback, provide solutions, or drive technological innovation. Although they may not directly bring economic returns, they may have value in other aspects, such as attracting investment, building a reputation, or laying the groundwork for future commercialization.
Under this viewpoint, choosing what "to do and not to do" is very important. Your decisions will ultimately yield: economic returns, project feasibility validation, user satisfaction, business reputation, etc. These outcomes need to be quantifiable to be used in the decision-making process of what "to do and not to do."
However, I think, regardless of whether it's interesting or boring, continuously doing the right things over a long period, treating time as a friend rather than a fling, is how to see the value of being boring.
