Clay Tech

"clay-works make things real"

translated from clazytech.com

The Basics Of Planning Are Not Thinking About Method First

original Startups

Product planning, business planning, promotional strategy — whatever the case, one thing holds true across all of them: method should be figured out later.

What happens if you focus only on method

Discussing method is a lot of fun.

If you’re an engineer, discussing implementation approaches, component selection, UI design — this kind of thing gets your brain absolutely boiling. Throw in the full knowledge and experience of the team, hash it out back and forth, and everyone is guaranteed to get fired up.

The same goes for business planning. Finish a single spreadsheet with carefully calculated numbers for funding plans, staffing plans, revenue forecasts, and somehow you get an enormous sense of fulfillment, even though the project hasn’t actually moved forward at all.

But in most cases, things don’t go that smoothly, and things don’t go as planned. And somewhere along the way, the project inevitably runs into a decisive either/or choice, or an issue where you can’t tell which answer is correct.

What should you do when that happens?

Local, piecemeal discussion almost never settles it. It’s a situation where one choice ripples through the whole thing, and a single mistake can ruin everything.

Now you’re stuck.

“Why won’t this method work?” “Why won’t this layout work?” “Why aren’t users taking to this feature?” “Why did we choose this user segment to begin with?”

Wave after wave of why, why, why.

And sometimes, after thinking and thinking and thinking, the conclusion ends up being “flip the table.” You arrive at the conclusion that “we should throw everything out and start over.”

It’s an unfortunate outcome, but honestly, reaching that conclusion is still pretty good. Far more often, people end up choosing to “force a decision on the spot despite lingering unease, and just push forward half-baked with eyes closed.”

That’s how a project dies.

I’ll leave it to your imagination what happens after that. (I’ll explain it another time if the occasion arises.)

Do the “whys” first

So to cut to the conclusion: ask “why?” and “why?” as early as possible, thoroughly, to the point of being almost annoying about it.

Let’s walk through this with an example.

The theme can be anything, but let’s say here we’re planning educational materials for programming education aimed at elementary school students.

When it comes to programming materials for elementary school kids, Scratch is the obvious choice. There are more and more teaching materials, like micro:bit, that let you do hardware implementation with Scratch, so a Scratch-based approach seems to open up a lot of possibilities. ESP32 is trendy these days, and there are game emulators that run on M5Stack — so what if we used a wrapper that lets you implement those in Scratch, built a simple game with it, and made a curriculum where everyone plays together? Wouldn’t that be fun?

And with that, the planning is done.

This is a bad example. It’s all talk about the product, the service, the technology. It certainly gets people excited, but it’s completely unclear what problem exists or what it solves. Products like this stumble the moment someone actually tries to “sell” them.

Sales rep: “What differentiates this product (curriculum)? What’s the pitch we use to sell it?”

There’s no clear answer to this fundamental question.

If the theme is programming education materials for elementary schoolers, start by asking an extremely fundamental “why.”

“Why do elementary school students need programming education in the first place?”

You might think, “Wait, all the way back to that?” But that’s genuinely where substantive planning begins.

The fundamental “why” determines everything

I’m only using programming materials as an example here, so I have no intention of pursuing that specific discussion to its conclusion (that’s for another time).

But it would be perfectly fine if the conclusion here turned out to be “there’s no need to teach programming to elementary school students.” The planning project would end, but if that’s the conclusion the team reached, it becomes the team’s policy, and if it’s something the company’s management decided, it becomes the business’s policy. Deciding “not to do” something carries just as much value as deciding “what to do.”

Let’s proceed with this thought experiment assuming a different conclusion was reached.

“Why do elementary school students need programming education?”

  • To maintain international competitiveness
  • To develop logical thinking skills

Listing too many would make this unwieldy, so let’s consider just these two for now. In an actual discussion, it’s preferable to list every idea you can freely come up with. For example, “programming helps you pick up English” is also a good angle.

Dig into “why” as deep as it goes

Let’s take up the “international competitiveness” angle here, for example. In fact, I’ve heard that while Japanese students’ math ability ranks highly internationally through junior high school level, the number of STEM PhDs is at a fairly disappointing level (if you’re interested, look up the specific numbers yourself). As an idea grounded in that kind of background, this seems quite promising.

Now, this can still be dug into further.

“Why does international competitiveness equal programming ability?”

Because the AI era is coming, and falling behind in AI technology means falling far behind industrially. Without programming ability, you’re not even on the competitive playing field, so it should be the single most important element of basic literacy.

“Is that really true?”

Looking back at history, there was a time when people hand-wrote HTML tags (the 1990s). That skill was highly valued at the time, but 30 years later, there’s no longer any occasion to type tags yourself, and even if you could, it wouldn’t count as a skill at all — its competitive value as a skill is essentially zero. What matters far more is properly thinking through the user story and experience (UX) of an entire website and being able to bring in the appropriate technology as needed. Teaching this to elementary schoolers means they won’t actually put it to use in the market for at least 10 years, and possibly 20. In a constantly shifting market, can we really, at this point in time, correctly predict what will actually be needed?

Suppose the discussion goes this way. The tide seems to be turning against it — but is it too hasty to give up on the competitiveness argument here and pivot sharply, saying “well then, logical thinking is what we should focus on instead,” as mentioned earlier? Let’s keep digging.

Dig deeper still

We’d like to start converging soon, but let’s dig one more level before backing out.

“Why is basic literacy necessary?”

If you can use Excel, is it fine not to be able to do addition? If there’s an autocomplete function for spelling, is it fine not to know the difference between “L” and “R”? If you can use CAD, can you design something without knowing drafting techniques? If there’s automatic translation, can you act as an interpreter and close business deals across regions with different languages?

Suppose at this point you feel something like “it’s not logical, but something doesn’t sit right.” You still feel that being able to do basic mental arithmetic is a good thing to have, and that a businessperson ought to be able to handle at least minimal English conversation on their own.

Having come this far, you may have arrived at something fundamental. Once you reach the layer where judgment is made not through logic or calculation but through reason and morality (or in some cases, intuition), digging any further doesn’t accomplish much. (For a philosopher, this might be exactly where the real work begins, but we’re practitioners here, so.)

You end up feeling that without at least a minimum of basic literacy, people will run into trouble once they enter society, or that there should be things they’re glad they learned once they enter society. And so, you want young people to acquire this as part of their intellect.

The logical path by which you arrive here varies case by case, and the conclusion itself will differ from person to person, team to team, company to company — that in itself isn’t a major issue.

Thinking about what already exists

The dimly perceived, fundamental hypothesis:

“Acquiring the literacy one should have as part of one’s intellect at a young age will ultimately help improve one’s abilities and raise international competitiveness, and programming may fall under that category.”

Once you’ve arrived at this, you need to think more analytically about how existing solutions measure up.

Again, whether or not this hypothesis is correct isn’t the point here, so don’t get too hung up on it. We’re only continuing the discussion of the thinking method here. Also, from here on there will be a bit more of what might sound like overreach (deliberately so), but that’s because without a certain amount of conviction and belief, a project can’t take on a sharp, distinctive edge.

Now then, let’s return to the bad planning example mentioned earlier.

Scratch’s approach — not tied to any specific language, defining program logic through UI manipulation — is very well thought out and impressive. (But it would be pointless to just keep praising it, so let me push back deliberately.) Couldn’t the following things be needlessly raising the barrier for basic literacy?

  • Requires one computer or tablet per student
  • Requires learning how to use a keyboard at this stage Also, aren’t the following serious gaps?
  • Without touching on matrix operations, it doesn’t contribute to developing AI talent
  • The process of writing a design document is missing, which risks instilling unplanned thinking

A few hypotheses about pain points have emerged here. And for issues like these, you naturally want some kind of supporting evidence. For example (note that the following is not based on fact):

“With a typical public elementary school’s budget, once computers are introduced, they can’t be replaced for 10 years.” “China ranks among the world’s top in AI-related papers, but only about 5% of lower-grade elementary students have ever touched a keyboard — not so different from Japan.” “The latest brain science research has revealed a major difference, between people accustomed to matrix operations and those who aren’t, in the ability to process tasks in parallel mentally — that is, in the level of complex task handling they can manage once they enter the workforce.” “A 40-year global tracking study has statistically shown a correlation where learning programming in the early grades is associated with a lower likelihood of entering fields requiring long-term planning, such as architecture, urban development, or policy.”

And so on. The above is nothing more than speculation, but if even one of these turned out to hold up as fact, wouldn’t a feeling emerge like:

“Things can’t stay this way! We have to change the world!”

This is Pain, and this is Passion.

Once you have this, the planning is essentially done.

After all this, we still haven’t thought about method

We’ve come a fairly long way to get here. Suppose the following planning concept ultimately emerged as a result.

Programming is important as basic literacy, but equipment preparation is a major burden. This isn’t a problem that can be solved simply through national or local government budget control. Also, learning how to use a computer isn’t really the essential goal — in fact, today’s teens are building a world where they get everything done on smartphones. We don’t know what the future holds. So, rather than using computers, if we develop an educational tool that lets students acquire programming-style thinking like Scratch does, and introduce it into schools cheaply, it can also be integrated with existing programming education curricula, and it should become a strong product that can compete globally. It could also draw on its low cost, durability, and lack of need for a power source to help spread programming education in developing countries.

I think this is a good product plan.

Up to this point, method of implementation hasn’t been considered at all. But it’s still a good plan. You can imagine whose pain it solves, and how it makes the world happier, once this is realized.

A variation on this, going a different direction, might also be interesting:

In the current education curriculum, matrix operations are taught in linear algebra — that is, only students who advance to a specific field after entering university learn this; it’s not general knowledge. This is the root cause behind Japan’s declining international competitiveness not just in STEM and AI fields but across industry as a whole. Therefore, matrix operations, macros, and functional thinking should be properly taught from a young age, but it will take an extremely long time before this gets incorporated into the official public education guidelines. So, first, propose a curriculum to private cram schools that don’t focus heavily on exam prep, and introduce it along with a self-developed tool capable of measuring learning outcomes. Once the business has grown, establish a dedicated cram school and vocational school. Ultimately, aim to gradually bring education boards on board and have it adopted into the official education curriculum.

This is a fairly wild idea, and honestly I don’t know whether it’s correct or whether it would truly succeed, but I think it’s an interesting plan. It makes you want to “find out what happens.”

Once a plan has been properly laid out like this… well, don’t you think you could come up with any number of ways to actually implement it?

Summary

That’s it — a story about the most basic of basics.

Originally published in Japanese at https://clazytech.com/2020/10/377/. Translated with LLM assistance and reviewed before publication.