Actually, every time I consult with the running buddies, I feel that it is a very good experience, which allows me to look back at how I got to where I am today.
Yesterday, I was consulting with student A, who was also a participant in the training program, and we talked about how I usually break down goals and what kind of guidance I use to break down tasks.
Then I thought about it carefully. In fact, when I break down tasks for a certain goal (for example, what do I need to do in Q3), I mainly use the WBS architecture, plus I think about it in conjunction with MECE. Is there any way to include all the tasks without omissions?
However, this is a very comprehensive and complete plan, which means I need to know which tasks I might have missed or which things I need to do.
But even though that's what I said, I later realized that what I actually did was this: I thought of a goal, and in the process of getting to that goal, there might be several "minimum feasible" steps or nodes. Basically, completing those is enough. The rest are just some details that don't affect the overall situation, which I can fill in later.
When I talked about this with a student yesterday, he was quite surprised and said it was a great method.
This made me start to reflect and realize that my decision-making patterns have always seemed to be like this. For example, suppose I wanted to create an online course, I would want to do it as quickly as possible, with the following specific steps:
- Pre-recorded preview lessons: Before officially recording the entire video series, I will pre-record two or three preview clips to let everyone understand my teaching style and course content.
- Social media distribution: Post these preview clips on social media to let people know that I am going to make this lesson, and continue to produce similar content.
- Continue to promote and sell: Begin to continuously post promotional articles to advertise and sell the course.
- Synchronized course recording: Once I've sold a certain number of courses, I'll lock myself away and record all the videos before uploading them.
- Subsequent minor adjustments: After the course sells out, I will go back and adjust some details that will not affect the overall situation.
I think this is one of the paths for online courses. Of course, there are many details that I haven't set up perfectly, but basically my goal is to "sell online courses." I mainly used these four nodes, and once they were completed, a small framework was established.
Now I'm making some small AI products myself, and it seems to be similar:
- The first thing is, what kind of problem do I hope this product can solve for me immediately?
- Then, I would examine each step to see if there's a minimum feasible option that can actually be implemented. For example: the UI needs a draft, the UX needs a user-defined workflow that others have already explored, and the screen sizes for computers, mobile phones, and tablets need to be easy to understand and operate. Does this product address several pain points for the target audience? This includes design and functionality, etc. Has a contact email address been provided? So that someone can reach me if there are any problems.
Once those stages are completed, the framework will be finished for me.
Thinking about it carefully, it seems that I have always done this in the past.
This made me quite curious. Had anyone else specifically suggested a similar idea before, or done the same thing as me? I later searched online and found that this approach of "building a movable skeleton first and then adding details later" has actually been mentioned by many people, and each has given it a name.
Let's start with the "skeleton" part:
- Walking Skeleton: A concept proposed by Alistair Cockburn in *Writing Effective Use Cases* (2000). First, make the entire path run smoothly from beginning to end, ensuring each link is as thin and mobile as possible, then gradually add more detail. My earlier point about "listing the smallest, most essential nodes to complete first" is essentially about selecting the skeleton.
- Gall's Law: Written by John Gall in *Systemanics* (1975). Almost every working complex system grows from a working simple system; trying to design a very complex system directly from scratch usually doesn't work. This law serves as a solid foundation for my approach.
- Minimum Viable Product (MVP): This term was coined by Frank Robinson in 2001 and popularized by Eric Ries in "The Lean Startup" (2011). It refers to creating a market-validated version with minimal effort and releasing it to test the waters. My process for creating online courses and those small AI products is essentially based on this.
Next is the matter of "adding details later":
- Technical debt: a concept coined by Ward Cunningham in 1992. His original analogy was: shipping goods in exchange for speed is like borrowing money from the future, which must be repaid later, with interest increasing the longer it's delayed. The difference lies in whether you "know what you owe" or "don't know at all." I belong to the former, provided I remember the debt.
- YAGNI (You Aren't Gonna Need It): This comes from Extreme Programming, a concept used by Kent Beck and his group. It means to only do things when you really need them, and not to waste effort on things you "might need later." This is almost a plain language version of my "put aside details that don't affect the big picture" philosophy.
Another interesting point is that the "rolling adjustment" I keep talking about actually has a formal name: rolling wave planning. It involves planning for the near future down to the details, and for the long term, first grasping the general direction and then gradually adding details.
Finally, regarding myself: Satisficing, a concept coined by Herbert Simon. Finding "good enough" and stopping is a very different decision-making style from maximizing. Simon later won the Nobel Prize in Economics for this series of research on decision-making.
So what I find quite interesting is that the things I've been doing based on intuition have actually been seriously considered by others, who have even given them names.
Perhaps the ability to adapt quickly in this fast-paced era, and to accomplish what I need with a very simple framework, is a remarkable adaptability. Having the theoretical support from these individuals in the past also gives me more peace of mind to do these things. :)
I wonder if you're the kind of person who builds a small framework and then charges straight ahead?
