2608: What Two Designers Taught Me About My Own Process

I spent last week at a business fes, mostly there to scout partners and see what else was out there. Two of the speakers were designers, walking through how they take a client from "we have a problem" to a finished product — understanding, problem definition, concept, prototype, then support after launch. Neither talk mentioned project management once. And yet by the end of the second session I was scribbling notes, because I kept recognizing my own work inside theirs.

I run GUC, a project management consultancy, and the thing I tell clients constantly is that you cannot apply a framework off the shelf. PMBOK, agile, lean — the principles hold, but the organization in front of you has its own history, its own scar tissue, its own unspoken rules. A framework laid on top without translation just sits there, technically correct and useless. Listening to those two designers back to back, I realized the sequence they were describing — dig into the real situation, define the actual problem underneath the stated one, shape something specific to that problem, test it small, then support it into place — was structurally the same sequence I already walk clients through when I propose how we'll run their project. I'd never once put those two disciplines next to each other before that day.

What made the similarity worth more than a passing observation was what came next: I started thinking about where design process could actually improve how I propose project management to a client, not just where it happened to resemble it. Designers are far more disciplined than PM practitioners tend to be about not designing anything until they've properly understood the person they're designing for. In my own proposals, I'd often move to "here's the process I recommend" faster than a designer would ever move to a concept. The affinity wasn't just interesting — it was a genuine gap I could close. If I borrowed the designers' patience at the front end, the project management approach I hand a client afterward would fit them the way a well-designed product fits its user, not the way a standard template fits any client.

That's a small shift in words but a real shift in practice: proposing project management as something designed for a specific organization, using a design process to get there, rather than proposing a methodology and adjusting it afterward. I left the fes convinced this wasn't just a nice parallel to notice once and forget. It's a discipline I should be borrowing on purpose, every time I sit down with a new client.

I haven't turned that into anything concrete yet, and I don't want to pretend otherwise. What I have is a question I keep returning to since the fes: where exactly, in GUC's own business process, would borrowing a real design discipline change what I hand a client? Not as a slogan about "designing projects," but as an actual sequence I hold myself to before I let any methodology leave the building. That's the part I want to work through properly rather than bolt on quickly.

The broader takeaway is one I keep circling back to in different forms: expertise that arrives ready-made, before anyone has properly understood the person receiving it, is the wrong kind of expertise, no matter how sound the framework is. Two designers who have never run a project management engagement in their lives gave me a clearer articulation of that principle than years in my own field had. That's usually how the useful lessons arrive — sideways, from people solving a completely different problem, who turn out to have already solved yours. Now I just have to do the slower work of actually building it into how GUC operates, instead of stopping at the observation.

2607 The Gift of Solitude: How Alone Time Nourishes the Brain

 

Say the word "solitude" and it often carries a lonely ring. In an age when connection is made visible through social media, spending time alone tends to be read as a bad sign — as if you have no friends, or don't quite fit in.

But I've always liked being alone. Time spent with others matters, of course, but the quiet time I spend alone — thinking, feeling, simply being — has always felt essential to staying grounded.

A book I read recently, The Brain at Rest by Joseph Jebelli, backs up this feeling with research.

Doing Nothing Puts the Brain to Work

When we drift, doing nothing in particular, a circuit in the brain called the Default Mode Network (DMN) switches on. Activating the DMN is linked to sharper intelligence, greater creativity, and higher productivity.

And the key that turns the DMN on is, of all things, solitude. Yet solitude keeps getting pushed aside. Modern life fixates on the benefits of social connection, and social media has woven itself so deeply into daily routines that alone time now gets treated as worthless — something to avoid rather than seek out.

The Great Thinkers Respected Solitude

Great thinkers, Thoreau among them, held solitude in high regard. Stepping away from society's noise, they found, let them see themselves more clearly. One researcher calls this moment "becoming present" — a sign, in neurological terms, that the DMN has begun to fire.

Writing, playing the piano — creative work like this often goes better alone. In that solitary time, the brain forms new synapses, sharpens skill, and nurtures creativity more effectively than it could in company.

Why I Ride Alone

I love heading out on my motorcycle by myself. I do go touring with friends now and then, but most of the time, I choose to ride solo.

The reason is simple: it's both "time alone" and a chance to fully immerse myself in the act of riding itself.

The sound of the engine, the resistance of the wind, shifting your weight through a curve — riding a bike demands constant attention to this moment, right now. You can ride while talking with someone, but doing so inevitably dilutes that sense of immersion.

It's precisely when I'm riding alone that the noise in my head falls away, leaving only the scenery in front of me and the sensations in my body. That, I suspect, is exactly the kind of brain-rest that solitude — the subject of this whole post — provides. Riding along in a half-daze, my mind ends up sorting itself out, quietly, almost without my noticing.

Touring with friends is fun too. But time spent riding solo is irreplaceable — it's time spent facing myself.

If Being Alone Feels Like a Bad Thing

If being by yourself carries a quiet sting of guilt or loneliness, you're far from alone in that. Many people have absorbed the idea that solitude is something negative.

But it's worth trying to see it differently.

In the Netherlands, there's a relaxation practice called niksen — sitting on a bench and watching people go by, or simply lingering in a café with nothing to do. Building this kind of "doing nothing" into daily life has been used as a way to manage stress and even depression.

There's also "mindful solitude" — sitting somewhere quiet and breathing, setting aside the same time each day to be alone, powering down your devices for that stretch. Small habits like these give the brain rest, and help restore creativity and the capacity to solve problems.

In Closing

Solitude might not be something to avoid at all — it might be an asset worth using wisely. Time spent with no one to compare yourself to, no one to accommodate, just facing yourself. That's not a sign of weakness. If anything, it's what makes you sharper and stronger.

The next time you notice you're alone, try reframing it — not as loneliness, but as the brain recovering, and creativity quietly taking root.

2606: The Compass, Not the Map

 One month ago I filed the paperwork and became a company. I didn't have a clean plan for what came next, just a hypothesis that the project management consulting I'd been doing informally would find its footing as something formal. What I didn't expect was how fast the scope would move. A month in, the work has already stretched beyond project management into process engineering consulting, because that's where the actual conversations with clients kept going. Nobody asked me to expand the offering. The clients did, just by talking to me about what was actually breaking in their organizations.

That expansion taught me something I thought I already knew but hadn't really tested: you cannot apply project management by the book. I mean that literally — take the textbook, take the framework, lay it over a real organization, and watch how much of it doesn't fit. Not because the principles are wrong. PMBOK, agile, lean, whatever lineage you draw from, the underlying logic holds up. But the actual company in front of you has its own history, its own scar tissue from past failures, its own unspoken rules about who can say what to whom in a meeting. A framework applied without translation just sits on top of that reality, technically correct and practically useless.

What I've been doing instead — and what I only fully understood by doing it for a month straight — is holding the principled version of "how this should work" in one hand, and sitting down with the client's own internal members to build the version that actually fits their company in the other. That second part isn't optional or secondary. It's the actual consulting. Anyone can hand over the ideal process on a slide. The harder, more valuable work is doing the tailoring together with the people who have to live inside that process every day, so what comes out the other end is recognizably theirs, not mine.

Here's the part that surprised me most: the clients I'm fortunate enough to be working with are genuinely excellent at this. I bring the navigation — here's the principle, here's why it exists, here's the direction — and instead of waiting for me to hand them a finished template, they take that and do the interpretation themselves, quickly and well. They ask the right clarifying questions, they push back where the principle doesn't map cleanly onto their reality, and they land on a tailored version faster than I could have designed it alone. I've started to think my actual job isn't delivering the process. It's pointing true north clearly enough that a capable team can chart their own route to it.

That's the broader lesson from month one: the value of this work was never going to be in how faithfully I could reproduce the textbook. It's in how well I can navigate — hold the principle steady, translate it into something workable in coordination with the people who'll own it, and trust that the more capable the client, the less I need to build for them and the more I need to build with them. A month ago I thought I was starting a project management consultancy. What I'm actually building is a practice in navigation, one client's tailoring at a time.

2605: Why "Working Together, Not Delegating" Is Our Real Advantage

Last week I wrote about putting my slide down mid-meeting and just asking what was actually going on — a small moment that sent me into Edgar Schein's "Humble Consulting." I finished the book still turning one idea over: the "Level 2" relationship, where a consultant earns enough trust that a client will finally say what's really wrong. I didn't expect that idea to circle back to something I already believed about my own company. But a few days later, sitting across from a prospective client who kept asking me to just tell him the scope, price, and timeline, it did.

He wanted what most Japanese companies default to when they need project management discipline: carve the function out, hand it to an outside PM firm, get a schedule and a status report back. It's a clean transaction, and on paper it looks efficient. It's also exactly the model Schein spends a whole book warning against — treating expertise as a deliverable you buy rather than a relationship you build. An outside firm shows up with the framework already loaded, produces the Gantt chart, and never gets close enough to hear about the turf conflict or the fear of losing face that's actually stalling the project. They were hired for what I've called koto — the schedule, the process, the paperwork — and structurally excluded from hito, the people problem underneath it.

That's the gap our philosophy, Working Together Not Delegating, was built to close, and reading Schein right before that meeting made me see why it isn't just a nice phrase on our website. A Level 2 relationship doesn't happen in a kickoff call and a signed SOW. It happens because someone sits inside the work with the client, week after week, humble enough to ask instead of prescribe. In a culture where hesitation, deference to hierarchy, and reluctance to say the uncomfortable thing out loud are baked into how meetings work, a delegated outsider almost never gets invited into that territory — there simply isn't enough shared history for the client to risk it. Someone who works alongside the team, rather than around it, has a real shot.

I told the prospective client something I wouldn't have framed this way a month ago: I wasn't going to quote him a fixed-scope PM package, because that's not actually the product that solves his problem. What he needed wasn't someone to take the project off his plate — it was someone to get on the plate with him long enough to find out why his team wasn't moving in the first place. He looked skeptical. Fair enough; it's a harder pitch than "we'll run the whole thing for you." But it's the only version of this work I actually believe produces something that outlasts the contract.

2604 What Edgar Schein Made Me Admit About My Own Advice

 I walked into a meeting this week ready with a recommendation. I'd done the analysis, I had the slide, I knew what the client should do — and within ten minutes the conversation had drifted somewhere the slide couldn't follow. Instead of forcing it back on track, I put the deck down and just asked what was actually going on. That single decision, and how uncomfortable it felt to make, is why I picked up Edgar Schein's "Humble Consulting: How to Provide Real Help Faster" this week, and why I couldn't put it down.

Schein's core claim is almost embarrassingly simple once you see it: most consulting fails not because the expert lacks expertise, but because the expert never builds a relationship honest enough for the client to say what's really wrong. He calls the alternative "Level 2" relationship — a shift from the polite, role-based distance most professional interactions default to, toward something closer to genuine personal trust. You get there not by demonstrating more competence, but by dropping some of it. Asking a real question instead of a leading one. Admitting you don't yet understand the situation instead of performing certainty you don't have.

I've spent most of my career being paid to have answers. Frameworks, methodologies, the right diagram for the right problem — that was the value I thought I was selling. What caught me this week is Schein's argument that the diagram is often the least useful thing in the room, because it answers a question nobody asked, dressed up as insight. The client's actual blocker is almost never a missing framework. It's usually something nobody has said out loud yet: a turf conflict, a fear of looking incompetent, a decision that was made for political reasons and now needs a technical justification. You can't PowerPoint your way into that territory. You have to be invited in, and the invitation only comes after you've shown you're listening for the real problem rather than pattern-matching to the one you already know how to solve.

The part that stung a little was Schein's distinction between "helping" and "being helpful." Being helpful is fast, visible, and often about the helper's own need to look competent. Helping is slower, requires tolerating not-knowing in front of a client, and starts with something as unglamorous as curiosity. Reading that, I recognized how often my instinct to have the answer ready was really an instinct to manage my own anxiety about looking unprepared, not a genuine read of what the client needed from me in that moment.

The broader takeaway I'm sitting with isn't really about consulting technique. It's that expertise and helpfulness aren't the same axis, and I've been optimizing the wrong one. The slide I put down this week wasn't wrong — it just wasn't the thing the room needed yet. Real help, it turns out, starts with humility about what you don't know, not confidence about what you do. That's a harder skill to build than any framework, and probably the one that matters more now than it ever has.

2603 Koto and Hito

 This week I sat down to write a memo for my CBL colleagues, and halfway through I realized I was really writing about the thing I've been circling for two decades of project management: there are two completely different jobs hiding inside the job title "project manager," and I've spent most of my career treating them as one.

In Japanese I split them as koto and hito. Koto — literally "the matter" or "the thing" — is the schedule, the budget, the risk register, the status report, the process. Hito — "the person" — is why a stakeholder is stalling, why a team goes quiet in meetings, why two departments that should cooperate instead quietly sabotage each other. For most of my career the two blurred together into one skill called "project management," and the koto side was where the credentials, the Gantt charts, and the professional identity lived. Hito was the messy overflow you handled with instinct, if you handled it at all.

What made me actually write the memo, rather than just think it, was watching how fast AI has started eating the koto side this year. Schedule optimization, cost forecasting, risk analysis pulled from historical data, progress reports auto-summarized from meeting transcripts — the tools I trained a generation of junior PMs to painstakingly build by hand are now something you generate in a prompt. And PMI saw this coming before I did: PMBOK's sixth edition, the one I studied for my own certification, was almost entirely a koto document — process, tools, techniques, prescribed in detail. The seventh edition, published in 2021, pivoted hard toward what they call "power skills" — principles for how a team actually creates value, not a checklist for how to run one.

That's not a coincidence. It's the largest project management body in the world quietly admitting that the technical half of the job was becoming commoditized well before AI made it obvious.

Here's the part that actually matters, though, and it's the part I underestimated for years: AI is extraordinarily good at statistical patterns, and hito problems are not pattern problems. "Why won't this team move" isn't sitting in a dataset — it's sitting in a history between specific people, in resentments nobody wrote down, in a culture gap nobody named out loud. You cannot prompt your way to that diagnosis. You have to be in the room, and you have to actually know the people.

This week an AI tool drafted a full project schedule, a cost forecast, and a risk register in a fraction of the time it used to take — work that once ate a full day of mine, back when I built these things by hand. I sat there a little stunned, and a thought I've circled for two decades finally clicked into words: project management has always been two different jobs stitched together, and I'm not sure the one I trained for is the one that matters anymore.

In Japanese I split them as koto and hito. Koto — literally "the matter" or "the thing" — is the schedule, the budget, the risk register, the status report, the process. Hito — "the person" — is why a stakeholder is stalling, why a team goes quiet in meetings, why two departments that should cooperate instead quietly sabotage each other. For most of my career the two blurred together into one skill called "project management," and koto was where the credentials, the Gantt charts, and the professional identity lived. Hito was the messy overflow you handled with instinct, if you handled it at all.

I'm not the only one who's noticed the split widening. PMBOK, the project management bible I studied for my own certification, was almost entirely a koto document in its sixth edition — process, tools, techniques, prescribed in detail. The seventh edition, published in 2021, pivoted hard toward what PMI calls "power skills" — principles for how a team actually creates value, not a checklist for how to run one. The largest project management body in the world quietly admitted the technical half of the job was becoming commoditized well before AI made it obvious.

Here's the part I underestimated for years, though: AI is extraordinarily good at statistical patterns, and hito problems are not pattern problems. "Why won't this team move" isn't sitting in a dataset — it's sitting in a history between specific people, in resentments nobody wrote down, in a culture gap nobody named out loud. You cannot prompt your way to that diagnosis. You have to be in the room, and you have to actually know the people.

So the koto knowledge I spent years accumulating — the tools, the methods, the certifications — is depreciating in market value in real time, whether I like it or not. But the hito work — reading what actually motivates a stakeholder, building a room where people function as themselves instead of performing a role, turning a cultural gap into leverage instead of friction — isn't just AI-proof. Its scarcity is going up precisely because everything around it is getting automated.

The broader takeaway, for me, is uncomfortable and clarifying at the same time: the parts of this career I was proudest of on my resume are the parts getting automated first, and the parts I used to file under "soft skills" are turning out to be the whole point. If that schedule is any indication, the koto side isn't coming back as a differentiator. The only question left is how deliberately I invest in the hito side instead of treating it as something that just happens if I'm lucky.

2602 GUC Is live

 I stared at a blank "publish" button for longer than I'd like to admit. Not because the website wasn't ready — it had been ready for days — but because clicking it meant the thing I'd been quietly building since I left T&T was no longer a private project. It was now a company other people could find, judge, and, hopefully, call. This week I clicked it. GUC — Growth Unlimited Co. — is officially live at guc-intel.com.

Two posts ago I wrote about why I was leaving. Last week I wrote about the disorienting first week of having no structure at all. This week the structure finally started to take shape, and it took shape around one decision I kept coming back to during every conversation I had this month: GUC will not be a firm that takes projects off your plate. It will be a firm that gets on the plate with you.

That distinction sounds like branding, but it's actually the whole thesis. I spent 25 years watching how expensive external advisory work usually plays out — a PM firm parachutes in, runs the project competently, and parachutes out, taking all the hard-won judgment with them. The client is relieved for eighteen months and then right back where they started, because nothing was transferred. I've been that parachuting expert. I got good at it. And I've decided I don't want to build a company on repeating it.

So GUC's model is deliberately less convenient for me and more useful for the client: work alongside the team, not instead of it, and treat "does the client's own staff walk away better at this" as a real success metric, not a nice-to-have. It's why the services page leads with advisory work embedded inside client teams, and only gets to training and organizational development — strengths-based, in partnership with CBL — once that embedded trust is established. You can't teach an organization to run itself if you're the one running it.

The insight that surprised me, building this out over the past few weeks, is how much that philosophy is really just lean thinking applied to consulting itself. Lean says don't build more process than the work needs. Applied to advisory services, it says don't build more dependency than the client needs either. Every EPC project I ever ran taught me that the healthiest projects are the ones where, by the end, the client barely needs the outside expert anymore. I'm trying to build a business whose success is measured the same way — not by how indispensable I become, but by how quickly I make myself less necessary.

The broader takeaway: if you're building something new, the model you choose says more about your values than your mission statement does. I could have built GUC around maximizing billable hours per client. Instead I built it around minimizing them, deliberately, because that's the version of this work I actually believe in. It's a harder way to run a company. It's also the only way I wanted to run one.

The site is live. The real work — the first client conversations — starts now.

https://www.guc-intel.com/

2601: Chasing the Pulse — Why I Traded Perfection for Passion

There is a particular kind of dissatisfaction that only comes from owning something flawless. For the past few years, I rode a Honda CB1100 — a motorcycle that, by almost every measure, gave me nothing to complain about. The engine was smooth and torquey, the reliability was unshakeable, and the classic styling turned heads at every stop. On paper, it was the ideal machine for someone like me: dependable, refined, and built to last. And yet, something was missing.

The Paradox of Perfection

The CB1100 never let me down — and that, oddly, became the problem. Every ride felt predictable. The engine hummed along with an almost engineered contentment, as if it were quietly reassuring me that everything was under control. There were no edges, no rawness, no moments where the machine surprised me. I began to realize: I was not truly riding the bike. I was simply being transported by it. This feeling reminded me of something I have observed in my professional life as well. Tools and processes that are too polished, too optimized, sometimes remove the very friction that keeps us engaged and learning. Comfort, taken too far, can quietly become complacency.

The Pull of the Twin

The BMW R nineT had been on my radar for some time. A boxer twin — an engine layout that is, in many ways, a deliberate step away from refinement. It vibrates. It pulses. The exhaust note is deep, mechanical, and honest in a way that modern multi-cylinder engines rarely are. What I wanted was not better performance. What I wanted was feeling. The moment I first opened the throttle on the R nineT, I understood the difference. The twin-cylinder pulse travels through the frame, through the handlebars, into your hands. The exhaust sound is not background noise — it is a conversation between you and the machine. Every gear change, every corner, every deceleration feels deliberate and alive.

Choosing Imperfection, Intentionally

This renewal was not a rational upgrade. By many technical metrics, the CB1100 was the superior daily companion. But motorcycling — like many things worth doing — is not purely rational. I think there is a broader lesson in this choice: sometimes we need to step away from the perfect to rediscover our passion. The R nineT demands more from me as a rider. It is less forgiving, more characterful, and requires genuine attention. And because of that, every ride feels like an event rather than a routine. As I approach my 50s, I find myself more drawn to experiences that are textured — rough around the edges, full of character, and genuinely engaging. The smooth and the seamless have their place, but so does the raw and the real. The CB1100 was a great motorcycle. The R nineT makes me feel alive.

2524: The Catalyst for Change—How a Slump Forced My Reskilling in Power BI

 

Hi, my valued followers.

I must sincerely apologize for the silence on this blog since August. After joining a project consulting firm, I haven't had the capacity to innovate my blog regularly. It wasn't just a matter of being busy; in fact, the overwhelming influx of new experiences created a kind of "slump" where I felt I needed to absorb rather than produce. I believe this period of professional realignment is a story best highlighted here.

Today, I want to write about my journey into reskilling, specifically my deep dive into Power BI.

The Old Challenge, The New Solution

I have always been passionate about automated processes using IT tools. Throughout my career—whether as an instrument engineer or a construction supervisor—my constant challenge was to visualize the up-to-date project status on a real-time basis. In the past, I had to rely on complex, command-heavy Excel tables, or even utilize system engineers to develop custom tools using platforms like Microsoft Access.

The frustration was always the same: The tools were too slow, too rigid, and required too much effort to produce a dashboard that truly reflected reality.

Now, tools like Power BI (in MS) and Looker Studio (in Google) are capable of solving these previous challenges. They generate dynamic, real-time dashboards that allow analysis from multiple aspects—the ultimate output for modern project controls.

Embracing the 40%ism of Learning

I started touching Power BI in November on my private basis, relying on YouTube tutorials and textbooks. I must admit, as a traditional user accustomed only to Excel, it has not been easy. It requires a fundamental knowledge of DAX (Data Analysis Expressions), which is an entirely new language.

I am still very much under the learning curve, but I am already confident that this tool is the path to achieving my desirable outputs for project controls.

The lesson here is simple: Year 2025 was a tough year, but the pressure stimulated me to expand my knowledge into new areas. If I were not in my current situation—if I were still relying on my old processes and familiar business tools—I may not have seriously attempted to learn Power BI. The necessity of a high-performance solution forced a much-needed reskilling.

I will write more about my thoughts after turning 50, but the common message remains forever true: We must continuously learn and find new ways to maximize our individual capabilities in life. I am deeply appreciative of my new colleagues and the environment that has pushed me toward this growth.

2523 Respecting Individual Strengths: Reflections on Eiji’s Path to Music and Achievement

 

A proud moment as my son’s band Mecha Bijin wins the Senko Riot Grand Prix — proof that passion and persistence lead to success. 

https://www.tfm.co.jp/lock/riot/

It has been almost a month since I last updated this blog — I was caught up in work and daily matters. Today, however, I want to dedicate this entry to my younger son, Eiji, and share his remarkable milestone.

On August 7th, his music group Mecha Bijin won the Senko Riot Grand Prix, a nationwide music competition for teenagers with more than 3,000 participating bands. To become the champion among such fierce competition is truly an extraordinary accomplishment. Eiji is the drummer of the group, a passion he has pursued since junior high school.

Our two sons have always taken very different paths.

• My elder son, Kansai, graduated from a prestigious preparatory junior high school, studied abroad in India at the age of 17, and is now immersed in liberal arts studies in Akita, living out his ideal student life.

• Eiji, on the other hand, decided early on to become a musician, leaving conventional schooling behind to attend a music academy.

I must admit, there were times when Eiji struggled, especially when comparing himself to his brother’s more traditional achievements. Yet what makes me proud today is not only his award, but the fact that he found his own career path and is realizing his dream on his own terms.

Behind this success lies an incredible amount of effort: countless hours of daily practice (sometimes more than 14 hours), supported by the professional electronic drum set we provided. He even gave up all his anime goods — once his favorite — to dedicate himself fully to drumming. Through his academy, his skills sharpened, his network expanded, and although he was never the most sociable, he never hesitated when it came to pursuing what he loves.

This achievement reaffirms my belief that a person’s true ability and results are maximized when they pursue their own strengths and passions. It may sometimes look like a detour, but respecting one’s unique preferences is, in my view, the surest path to success and happiness.

One regret remains: on that very day, August 7th, I was at my flat in Osaka and could not attend the event in person. Perhaps my biggest blunder of 2025… but even so, my pride in Eiji’s achievement is immeasurable.

2522 Why Do Our Customers Really Come to Our Shisha Bar?

 

July is always a tricky month for us. It’s the periodical test season at universities in Kyoto, and that means our usual flow of student customers slows down.

Our shisha bar, Zerobase, is located in Demachiyanagi, right in the heart of Kyoto’s university area. We’re surrounded by major schools—Kyoto University, Doshisha University, Ritsumeikan University. Many of our regulars are students, especially those from Kyoto University, since the Commodity Faculty is just across the street.

But during exam season? They vanish into the libraries. And unfortunately, this month’s revenue fell below average.

Our store manager, Kenji, came to me for advice:

“How can we minimize the impact this month?”

He proposed a simple idea—a short-term student discount during the exam period.

As usual, I told him:

“If you believe it’ll work, go ahead. It’s your call on how to turn things around.”

But something kept me thinking. I remember that I recently re-read a book that I love, “Competing Against Luck” by Clayton Christensen, which introduces the Jobs to Be Done framework.

So I asked Kenji a simple but powerful question:

“Why do our customers really come to our shisha café?
Is it because the price is cheap?
Because the flavors are unique?
Because you’re handsome?
Or maybe because our drip coffee is special?”

He went silent.

So I gave him a summer task: read the book and summarize it in a simple report.

A week later, he called me back. Instead of going for a discount campaign, he suggested something different:

“Let’s hold a collaboration event with a fortune teller. Lowering prices won’t necessarily bring more customers, and it could even have a negative effect on how other customers perceive our value.”

His idea wasn’t exactly what I expected, but I agreed with his decision. More importantly, I was happy to see him thinking beyond just price.

What I really wanted him to discover was this:

Which “customer jobs” can our shisha café truly solve?

This little episode might be the trigger for Kenji to start prioritizing the Jobs to Be Done mindset in his marketing decisions. And for me, that’s already a step in the right direction.

2521 Still Exploring My Style as a Consultant

 

It has been six months since I began working as a consultant. I often find myself wondering—am I truly qualified to call myself one?

The term consultant implies someone who provides valuable advice to clients. This advice is often expected to be specific, actionable, and result-oriented. In many cases, the clearer the recommended actions and the more measurable the outcomes, the better.

But what if that’s not my strongest suit?

If the ideal consultant is someone who gives sharp, one-way directions toward a defined result, then maybe I’m not that kind of consultant. I tend to value individual autonomy over issuing rigid instructions. In this blog, I often speak about concepts like effortlessness, reframing, and the power of autonomy—all of which suggest that there is rarely a single "right" way to do things. Instead, there are countless unique paths shaped by individual strengths and perspectives.

For example, I may see the most direct route from A to B. But someone else, using their own strengths, might find it more effective to go from A through C to B. That’s not a mistake—it’s their way, and in many cases, it might even be better.

This belief doesn’t just shape how I work with clients—it also shapes how I manage my team. Whether I’m acting as a consultant or as a manager, I try to create an environment where people can tap into their own capabilities, think for themselves, and discover the most effective approach for them. I don’t want to impose my judgment if there’s room to encourage theirs.

Of course, in real business situations, there isn't always time to explore all the possibilities. When time, budget, and resources are limited, we often default to top-down decision-making. In such cases, a single action must be taken quickly—and sometimes, that's necessary. But whenever time allows, I resist the urge to give one-way advice. I aim to hold space for dialogue and discovery.

So yes, I am still exploring what it means to be a unique and professional consultant. But I know what I aim for: to deliver value and satisfaction to both my clients and my team, by maximizing their individual strengths, not by replacing their judgment with mine.

Maybe that’s not traditional. But maybe that’s exactly the kind of consultant—and manager—I’m meant to be.

2520 “Done Is Better Than Perfect” – Why 70% Is Enough to Start

 

Mark Zuckerberg of Facebook famously said, “Done is better than perfect.”
It’s a powerful mindset shift—especially in Japan, where many young professionals hesitate to share their work unless they feel it’s flawless.

I’ve written about this before, but now that it's June, I feel the need to revisit the idea. Many new employees who joined companies in April are likely struggling with the same issue my team member Kenji recently faced.

The concept is what I call “70%ism.”
In short: Don’t aim for 100% perfection from the beginning. Aim for 70% completeness. Why? Because that’s often good enough to start meaningful discussions, receive feedback, and move forward efficiently. And most importantly, it avoids unnecessary delays caused by chasing perfection.

When experienced professionals prepare a slide deck or a concept note, 70% completeness can often be achieved in 2–3 hours—even for heavy topics. On the other hand, pushing from 70% to 90% or more usually requires double or even triple the time. That extra effort upfront isn’t always justified, especially if the direction might change after feedback.

A few weeks ago, I asked Kenji, a new graduate who joined in April, to explore business ideas outside of our current shisha bar operations. I asked him to summarize a business flow that our IT team could use to begin prototyping a new service.

I expected something rough within a week. But three weeks passed, and nothing came.
Kenji was stuck—he felt he couldn’t present his idea unless it was polished and complete. To him, even producing something 70% done felt like showing 90% of his full effort—and he wasn’t confident enough yet.

So I gave him a new target:
“Forget 70%. Just give me 40%. Spend no more than two hours. Don’t overthink it—just get the idea out.”

He looked a bit embarrassed, but smiled. Two days later, he submitted a few memos and gave a verbal explanation. It wasn’t fancy—but it was clear enough. And our IT staff immediately understood the direction and got started.

If you’re managing new graduates, you might face a similar situation. Perfectionism holds people back—especially when they’re just beginning. For first assignments, I actually recommend aiming for “40%ism.” It encourages early output, builds confidence, and prevents the paralysis that comes from trying to be perfect.

Perfection can wait.
Progress starts with action—even if it's only 40% complete.