Seeing Flat Problems as a Cube
Most problems look flat at first.
"We need to build this feature," "We need to fix this screen," "Revenue is not growing." If you only see one surface, it feels like solving that one surface will be enough.
But living problems inside products almost always have multiple surfaces at the same time. The surface of technology, product planning, design, operations, brand, and even the surface of using AI. Turning a problem like a cube instead of treating it like a flat plane. That is how I solve problems.
And this is not just a phrase that sounds good. It is a method I have repeatedly verified through actual work.
Start by using it yourself and collecting every place where a question mark appears
The first thing I do when solving a problem is to use the product myself.
Reading a spec and looking at data matter, but the most honest information comes from direct experience. As I use it, I collect every moment that triggers questions like, "Why do I hesitate here?" "Why do I not want to click this button?" and "Why does this flow feel awkward?"
Then I look at the data. I check whether users also drop off where I felt friction, or whether it was just my own discomfort. Then I reinforce what works, and patch or hedge what does not.
By "hedge," I do not mean removing every weakness unconditionally. If a hurdle is structurally necessary, I reduce its burden through design. For example, if sign-up is a conversion bottleneck but still essential to the service, I would not remove sign-up itself. I would let users experience the core value first, so they have a reason to sign up.
That is the starting point of my problem solving. I do not begin by fixing one surface. I begin by understanding the full context of the problem.
What I learned from launching ten apps
At App in Toss, I have directly planned, built, designed, and operated more than ten mini-apps. At first, I built them to solve problems that I personally found frustrating. I targeted people with similar pain points, and one of the apps whose hypothesis proved correct reached 200,000 users in just two months.
What mattered there was not just building a good feature.
Even with a single push notification, I kept testing what situation the user was in when receiving the message and what wording actually led to action. At Toss, a push click-through rate of 3% is considered good, and pushes are disabled if the numbers stay below 4% for a period of time. My apps averaged in the 5% range and peaked at 6.8%. That result came from the combination of convenient design, validated pain points, and AI-assisted marketing optimization.
Of course, not everything succeeded.
I also made a rolling-paper app where users could leave supportive messages for friends, but writing a rolling paper inside Toss itself was too high a hurdle for users. Both ad conversion and user conversion were terrible, and it remained a failed product. The feature worked, but the product hypothesis was wrong. That experience taught me to ask not "Does this function work?" but "Is this action natural in this context?"
There was another case. In the early days of App in Toss, when there were not even 200 apps on the platform, one app entered early. As time passed, copycat apps flooded the category and users started leaving. When DAU dropped to around 10, I analyzed the strengths and weaknesses of competing apps and rebuilt the app from the ground up. As a result, I raised DAU to 120, and I am still operating it while continuously improving usability.
What I learned in that process is simple: keeping something alive is harder, and more important, than simply making it.
I work the same way outside digital products
This cube-like way of thinking is not limited to digital products.
I once worked on a cafe branding project. It was a short three-month freelance position, and when I first diagnosed the business, the biggest problem was clear: the cafe had no face. There was not a single menu item that deserved to be called a signature.
Looking at the sales data, sweet pastries were selling well. I decided to combine that insight with local heritage and create a signature bread. That required long coordination with the bakery team. As an external contributor, I could not have pushed this direction at all if I had failed to build a relationship with them. Execution moved quickly. Make it, sell it, watch the response, change it, and sell it again. I repeated that cycle.
At the same time, digital work moved in parallel. I optimized Naver Map, worked on SEO, and ran performance marketing on Instagram, which was the main channel used by the target customers at the time. The cafe was in an awkward location, but we still raised the ratio of walk-in customers who did not come by car to 40%. Total revenue increased by 30%.
It is hard to define what I did in that project as a single job function. Data analysis, menu planning, branding, marketing, and operational improvement all existed inside one connected flow. That felt natural to me. If a problem has many surfaces, approaching it from many surfaces at once is the obvious thing to do.
AI is both a tool and a workflow
I do not use AI as "a tool I ask once in a while." I embed it into the way I work.
When I build an app, my process looks like this. I first write a spec in a spec-driven way. Based on that document, Claude Code and Codex each generate code, and the outputs cross-check one another. QA is run through Codex, and the error reports that come out of it are fixed through Claude Code.
I also created skill.md documents that formalize the standards and patterns for recurring work. It is a semi-automated human-in-the-loop system. With this approach, the time required to launch one app dropped from three weeks to four or five days. It still requires occasional manual checking, but with current technology I believe this is the highest-quality method.
The goal is not to ship fast for its own sake. Once speed increases, quality can fall just as easily. So now I choose density over volume. The time I save goes back into planning and design, and I focus on building outcomes worth keeping in a portfolio.
There are a few rules I keep when using AI.
I structure the problem before I ask AI anything. Unstructured questions lead to unstructured answers. I get drafts quickly, but I judge them slowly, because a sentence that sounds plausible is not necessarily correct. For decisions involving technology choice, cost, or policy, I always verify again with official documentation and real-world constraints.
And the most important rule is this: do not lose my own standards while using AI. AI tends to make outputs look clean and average. But in the process, my sense of the problem or the texture of the product can get blurred. I explore widely, but the final result still has to preserve the standards that matter to me. Tools do not decide direction. People do.
Six surfaces, one direction
To summarize, when I look at a problem, I rotate all six surfaces together.
Is it sustainable technically? Does it identify the real problem from a product perspective? Is the design understandable without making the user think? Can it survive operationally after launch? What impression does the product create as a brand? And how should AI be woven into that flow?
This does not mean I am the best person in every surface. In each area, I may not go deeper than a specialist. But I do think I have a strong sense for seeing how those surfaces connect. And I have actual experience turning those connections into working systems.
Creating a service with 200,000 users by handling everything from product planning to marketing at App in Toss, building a signature menu and lifting revenue by mixing data with field intuition at a cafe, and cutting launch time by a factor of five through AI workflow design: these are all different expressions of the same method.
Being a multiplayer does not mean being able to do a little bit of everything. It means looking at one problem from multiple surfaces at the same time and binding those surfaces so they move in one direction. One source, multiple uses. Starting from one perspective and solving it through technology, product, design, operations, brand, and AI.
As AX becomes more important, I expect this kind of workflow to move closer to the center.
I am not someone who arrives at the answer fastest. I am closer to someone who sees a problem across multiple layers at once and tries to bundle it into an answer that can actually last.
Turning a flat problem into a cube.