Think about method last when planning a project

Whatever the case — product planning, business planning, promotional strategy — one thing holds true across all of them: you should think about the method later.

What happens when you focus only on the method

Discussing methods is a lot of fun.

If you’re an engineer, discussing implementation approaches, component choices, UI design — that stuff gets your brain boiling. Throw in the full knowledge and experience of every team member and go back and forth on it, and it’s guaranteed to get lively.

For business too, once you’ve finished a spreadsheet with carefully calculated numbers for funding plans, staffing plans, sales projections, you get an overwhelming sense of fulfillment — even though the project hasn’t actually moved forward at all.

But in most cases, things don’t go that smoothly, don’t go as planned. And somewhere along the way, every project runs into a decisive either-or, or an issue where nobody can tell which answer is right.

What should you do when that happens?

Local discussion almost never settles it. It’s a situation where one choice ripples through the whole project, where 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 in the first place?”

The whys come flooding in.

And sometimes, after thinking and thinking, the conclusion you reach is to “flip the table.” You conclude that “we should throw everything out and start over.”

That’s an unfortunate outcome, but honestly, reaching it is still the better case. Far more often, people choose to “force a conclusion out of the discussion right there despite the nagging discomfort, and push forward half-baked with eyes closed.”

That’s how a project dies.

I’ll leave it to your imagination what happens afterward. (I’ll go into that some other time.)

Do the “why-whys” first

So to cut to the conclusion: ask “why?” “why?” as early as possible — thoroughly, to the point of excess, to the point of being annoying.

Let’s walk through this with an example.

The theme can be anything, but let’s say here we’re planning a programming education product for elementary school students.

When it comes to programming materials for elementary schoolers, Scratch is the obvious choice. There are more and more materials, like micro:bit, that let you implement hardware with Scratch, so if we think Scratch-based, it seems like we could do all kinds of things. Say, ESP32 is trendy lately, and there are game emulators that run on M5Stack — what if we used a wrapper that lets us implement those in Scratch, built a simple game with it, and created a curriculum where everyone plays together? Wouldn’t that be fun?

Planning done.

This is a bad example. It’s all product, service, and technology talk. Sure, it’s lively, but it’s completely unclear what problem exists and what’s being solved. Products like this stumble the moment it’s time to actually “sell” them.

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

There’s no clear answer to that essential question.

If the theme is programming education for elementary schoolers, you should really start by throwing out an extremely fundamental “why.”

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

Huh? Starting there?? You might think that, but genuine planning actually starts exactly here.

The fundamental “why” decides everything

I’m only using programming education as an example here, so I don’t intend to dig all the way through that particular discussion (that’s for another time).

But here, an answer like “elementary schoolers don’t need to be taught programming” would also be a legitimate conclusion. It would end the planning process, but if that’s the conclusion the team reached, it’s the team’s policy; if it’s what company leadership decided, it’s the business’s policy. Deciding “not to do something” carries just as much value as deciding “what to do.”

Let’s assume a different conclusion was reached and continue the thought experiment.

“Why do elementary school students need programming education?” – To maintain international competitiveness – To develop logical thinking skills

Listing too many gets unwieldy, so let’s consider these two for now. In an actual discussion, it’s better to list everything you can freely think of. 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. In fact, I’ve heard that while Japanese students rank near the top internationally up through junior-high-level math ability, the number of PhDs in science and math fields is quite dismal by comparison. (If you’re curious, look up the actual figures yourself.) As an idea grounded in that kind of background, this seems fairly reasonable.

Now we can dig 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 starting line of competition — it should become the single most important element of basic literacy.

“Is that actually true?”

Looking back at history, there was a time when people wrote HTML tags by hand (the 1990s). That skill was valued back then, but 30 years later, there’s no occasion to type tags yourself anymore, and even if you could, it wouldn’t count as a skill at all — its competitive value as a skill is zero. What matters far more is properly thinking through the user story and experience (UX) of a website as a whole, and being able to deploy the right technology at the right time. Teaching this to elementary schoolers means they won’t put it to effective use in the market for at least 10 years, possibly 20. In a market that keeps changing, can we, right now, correctly predict what will actually be needed?

Say the discussion goes that way. The odds look bad. But abandoning the competitiveness argument here and pivoting hard toward “well then, it must be logical thinking after all” seems a bit premature. Let’s keep digging.

Dig further

We’re getting close to wanting to converge, but let’s dig once more before pulling back.

“Why is basic literacy necessary?”

If Excel is available, is it fine not to be able to do addition? If there’s spell-check autocomplete, is it fine not to know the difference between “L” and “R”? If CAD is available, can you design without knowing drafting technique? If there’s automatic translation, can you close business deals as an interpreter across language barriers?

Suppose here you feel “it’s not logical, but something doesn’t sit right.” You feel that people really should be able to do basic mental arithmetic, and that as a businessperson, you should be able to hold at least a minimal conversation in English on your own.

At this point, you’ve probably reached something fundamental. Once you arrive at a layer where judgment is made not by logic or calculation but by reason, morality, or (sometimes) intuition, digging further doesn’t accomplish much. (For a philosopher, this might be exactly where the real work begins, but we’re practitioners here.)

You conclude that without at least a minimum of basic literacy, people run into trouble once they enter society, or there are things they’ll be glad they learned once they’re out in the working world. So you want young people to acquire this as part of their intelligence.

The logical path to reach this point varies case by case, and the conclusion itself varies by person, by team, by company — that itself isn’t a major issue.

Thinking about what already exists

Given the dimly perceived fundamental hypothesis:

“Acquiring, at a young age, the kind of literacy one should have as part of one’s intelligence ultimately helps improve capability and raise international competitiveness, and programming may qualify as such.”

we need to think more analytically about what already exists in that light.

Again, whether this hypothesis is correct isn’t the topic here, so don’t get too hung up on it. We’re only continuing the discussion of thinking method. Also, from here on there will be a somewhat larger dose of overreach (deliberately so), because without a certain amount of conviction and assumption, a project never gets sharp edges.

So, back to what came up in that bad planning example earlier.

The way Scratch works — not tied to a specific language, defining program logic through UI operations — is very well thought out and I think it’s excellent. (But it’s no good just praising it, so let me push back.) Couldn’t the following be needlessly raising the bar for basic literacy? – Requires one PC or tablet per student – Students have to learn how to use a keyboard at this stage And couldn’t the following be considered a serious gap? – Without touching on matrix operations, it does nothing to develop AI talent – The absence of a design-diagram-drawing process risks instilling unplanned thinking habits

A few hypotheses about pain points have now surfaced. For pain points like these, you’ll want some kind of supporting evidence. For example (note: the following is not based on fact):

“A typical public elementary school’s budget means that once PCs are introduced, they can’t be replaced for 10 years.” “China ranks among the world’s top producers of AI-related papers, but only about 5% of lower-grade elementary students have ever touched a keyboard — not so different from Japan.” “Recent brain science research has shown a large difference, between those accustomed to matrix operations and those who aren’t, in whether they can process tasks in parallel mentally — that is, in whether they can handle complex tasks once they become working adults.” “A 40-year global tracking study has statistically shown a correlation: children who learn programming in the lower grades are less likely to end up in careers requiring long-term planning, such as architecture, urban development, or policy.”

And so on. The above is pure fabrication, but if even one of these turned out to be true, wouldn’t something like this well up:

“We can’t keep going like this! We have to change the world!”

That’s Pain, and that’s Passion.

Once you have that in hand, the planning is essentially done.

In the end, we haven’t thought about method at all

We’ve come a fairly long way to get here. Suppose, as a result, we arrive at a planning concept like the following:

Programming is important as basic literacy, but equipment preparation is a major burden. This is not a problem that can be solved just by controlling national or local government budgets. Also, learning how to use a PC is not really the point — today’s teens already live in a world where everything is done on a smartphone. We don’t know what the future holds. Given that, the answer is to develop an educational tool that lets students build programming-style thinking without using a PC, like Scratch does, and roll it out cheaply into schools; it could then merge with existing programming curricula, becoming a strong product able to compete globally. Also, its low cost, durability, and lack of any need for a power source could help spread programming education in developing countries.

I think this is a good product plan.

Up to this point, not a single method of realization has been considered. But it’s still a good plan. It lets you picture whose pain gets solved, and how the world becomes happier as a result.

Here’s another curveball that might also be good:

In the current curriculum, matrix operations are taught only within linear algebra — a category studied only by those who enter a specific field after going to university, not something taught generally. This is the root cause behind Japan losing international competitiveness not just in science and math or AI, but across industry as a whole. So matrix operations, macros, and functionalization should be properly taught from a young age, but it will take an extremely long time before this gets included in the national or public school curriculum guidelines. So the plan is to first propose a curriculum to private cram schools that don’t focus heavily on exam prep, and introduce it together with a self-developed tool that can measure learning outcomes. Once the business grows, establish a dedicated cram school and vocational school. Ultimately, aim to gradually bring in the board of education and get it adopted into the official school curriculum.

This is a pretty far-out idea, and honestly I can’t say whether it’s right or whether it would actually succeed, but I think it’s an interesting plan. It makes you want to know how it turns out.

Once a plan is properly built like this… well, don’t you think you could come up with any number of ways to realize it?

Summary

• Set the question of method aside for now
• Once you’ve set a theme and formed an image of what you want to do, first throw out the fundamental “why”
• Keep digging into “why” while selecting hypotheses along the way
• Once you reach the point where judgment is made in a domain beyond logic, stop digging and shape the hypothesis
• Organize that hypothesis into the form of a product plan

That’s the story of the basics of the basics.

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