Solve Before Build

Yohei Kano (aka Hey9Woz)

Table of Contents

Introduction

When you work as an engineer, it is very easy to let your mind drift toward how to build.

  • architecture
  • implementation detail
  • performance
  • readability
  • safety of change

All of those matter. None of them should be dismissed.

But by themselves, they do not create value.

Real projects involve clients, shifting requirements, mismatched assumptions, and people looking at the same problem from different positions. If you focus only on "building it correctly," you can still end up shipping something that nobody really needed.

That is why I keep coming back to one idea:

Before asking what to build, ask what problem is actually worth solving.

This article is about that order.

TL;DR

  • Engineers are naturally trained to think in terms of implementation.
  • That strength can become a bias.
  • In existing systems especially, "safe change" can drift into "change with no value."
  • The better first question is not "What should we make?" but "What should become better?"
  • Good technical judgment often requires moving back and forth between implementation and business meaning.

Why Engineers Get Pulled Toward Implementation

Engineering education and engineering work both reinforce the same instincts:

  • how to design
  • how to implement
  • how to change safely
  • how to improve without breaking things

That is not a weakness. It is part of the job.

But once those instincts become dominant, the center of discussion can quietly shift. You start hearing questions like:

  • Can this design work?
  • How far does the impact spread?
  • Which option is cleaner?

Those are good questions. They just are not always the first questions.

When the order flips, something subtle happens: you can end up with a technically sound result that is weak as a piece of value.

The Common Failure Mode in Existing Systems

This problem shows up very easily in existing systems.

When you are changing something large and already in production, minimizing impact is obviously important. Stable operation depends on it.

But if "minimize impact" becomes the dominant rule, another state appears:

no bug, no incident, no real improvement either

The behavior is preserved. The tests pass. The review passes. But the user problem is still mostly where it was.

That is a dangerous kind of success because it looks responsible. From the outside, it can even look high quality.

Still, if the original friction remains, then the work has not really solved much.

Start with What Needs to Be Solved

The core mistake is simple:

we start from what to build instead of what to solve

The healthier order is the reverse.

Technology is a means. Implementation is not the goal. It is only part of the route toward a better state.

So before discussing screens, APIs, or mechanisms, I think it helps to ask:

  • Who is struggling?
  • What is blocked?
  • Is this actually worth solving?
  • What changes if we solve it?

Those questions do not replace engineering. They frame it.

And once you have the frame, technical decisions become easier to evaluate. You are no longer choosing only between elegant options. You are choosing between ways to deliver a specific improvement.

Temporarily Forget That You Are an Engineer

One habit that helps me is very simple:

for a moment, forget that you are an engineer

If you were on the business side, what would you actually want improved? What would matter to users? How would this affect sales, operations, or decision-making?

Then, after looking from that side, return to the technical side.

That back-and-forth matters.

Without it, you can build something that is clean, stable, and carefully reviewed, but still oddly weak. With it, you are more likely to end up with something that is not only correct as implementation, but correct as value.

I do not think the job is to become "half business person" or to abandon technical depth. The job is to be able to move between both worlds when needed.

Why This Order Matters to Me

Part of the reason I care about this is personal history.

I started my career in sales. At that time, I did not have many advantages beyond youth and willingness to work hard.

So I learned to save time where I could: script repetitive work, reduce waste, and create room for the parts that actually moved results.

That experience trained a certain order into me. First ask what needs to happen. Then choose the means.

Now, as a software engineer, I often work around large EC systems and existing services where business conditions move quickly. In that kind of environment, implementation alone is not enough.

You also have to think about things like:

  • design intent
  • SEO
  • operational cost
  • revenue impact

If you do not, you can still arrive at something technically correct but commercially weak.

That is why I do not want to be trapped too tightly by the label of "engineer." I want to move where the problem actually is.

What Should Stay Stable in a Changing Technical World

Technology keeps changing. That part is not optional.

What can stay stable is the order of thought.

If you consistently ask what should be solved before deciding what should be built, you create a better chance of protecting time, attention, and value inside technical change.

To me, that is one of the few durable foundations available in software work.

Summary

If you change only one thing, change the first question.

Do not begin with:

What should we build?

Begin with:

What should become better?

That small shift changes how implementation gets evaluated. It becomes easier to treat code as a means instead of an end.

And in the long run, the things that stay useful are usually not the things that were built most elegantly. They are the things that actually solved the right problem.

If you want more background on how I moved from sales into engineering and why I care about this boundary between technology and value, I also wrote a short piece on Wantedly:

From Sales to Engineer