The Problem with Traditional Development
Most developers are trained to think in terms of features. "Build this button." "Add this page." "Implement this API." And there's nothing wrong with that—it's how software gets made.
But here's what I've learned after years of working at the intersection of engineering and growth: the best code in the world is worthless if it doesn't move the needle.
I've seen beautifully architected systems that nobody uses. Perfectly optimized databases that track meaningless metrics. Elegant solutions to problems that didn't exist.
The growth engineering mindset flips the script. Instead of asking "what should I build?", you ask "what outcome am I trying to create?"
What Growth Engineering Actually Means
Growth engineering isn't a job title—it's a way of thinking. It's the discipline of applying engineering rigor to growth problems.
Here's what that looks like in practice:
1. Start with the Metric, Not the Feature
Before writing a single line of code, I ask myself: "What number will change when this ships?" If I can't answer that question clearly, I'm probably building the wrong thing.
This doesn't mean everything needs to be directly tied to revenue. Sometimes the metric is "time to first value" or "activation rate" or even "developer happiness." The point is having a clear, measurable target.
2. Optimize for Learning Velocity
The fastest-growing companies I've worked with share one trait: they learn faster than their competitors. They ship experiments quickly, measure rigorously, and iterate without ego.
As a growth engineer, my job isn't to build perfect systems. It's to build systems that let us learn quickly. That means:
3. Think in Systems, Not Silos
Growth doesn't happen in a vacuum. A signup flow connects to onboarding connects to activation connects to retention connects to referral. Touch one part and you affect the whole.
The best growth engineers I know think like systems architects, even when working on seemingly isolated features. They ask: "How does this fit into the larger machine? What upstream and downstream effects will this have?"
The Kyokushin Connection
You might be wondering what martial arts has to do with growth engineering. More than you'd think.
In Kyokushin karate, there's a concept called "Osu" that roughly translates to "push through" or "persevere." It's about maintaining discipline when things get hard, staying focused on long-term mastery rather than short-term comfort.
Growth engineering requires the same mindset. The work is often unglamorous—debugging tracking implementations, optimizing load times by milliseconds, writing copy variations for the hundredth A/B test. It requires patience and discipline.
But like martial arts, the compound effects are enormous. Small improvements, consistently applied, create transformational results.
Practical Applications
Let me give you a concrete example from my work at Wander.
We had a personalization problem. Users were seeing the same properties regardless of their preferences, past behavior, or booking patterns. The standard solution would be to build a recommendation engine—a big, complex ML project.
Instead, I approached it as a growth engineering problem:
Step 1: Define the metric. We wanted to increase "property-to-booking conversion rate"—the percentage of users who book after viewing a property page.
Step 2: Find the fastest path to learning. Instead of building a full ML system, we started with simple rules-based personalization. Users who had previously booked beachfront properties saw more beachfront properties. Users who traveled with families saw family-friendly options.
Step 3: Instrument everything. We built comprehensive tracking so we could see exactly how personalization affected behavior at every step of the funnel.
Step 4: Iterate based on data. The simple rules worked surprisingly well. Only after validating the approach did we invest in more sophisticated ML models.
The result? A 40% increase in property-to-booking conversion, achieved in a fraction of the time and cost of a traditional approach.
The Mindset Shift
If you want to develop a growth engineering mindset, start with these shifts:
From "What should I build?" to "What outcome do I want?"
From "Is the code clean?" to "Is the code teaching us something?"
From "Ship and move on" to "Ship, measure, learn, iterate"
From "My job is engineering" to "My job is creating business outcomes through engineering"
This doesn't mean abandoning engineering excellence. It means redefining what excellence looks like. The best code isn't the most elegant—it's the code that creates the most value.
Conclusion
The growth engineering mindset isn't something you learn once. It's a practice, like martial arts. You develop it through repetition, through failure, through constant refinement.
But if you can master it, you become something rare: an engineer who doesn't just build things, but builds things that matter. Someone who can see the whole system, understand what levers to pull, and execute with precision.
That's the intersection of code and strategy. That's growth engineering.
If you found this useful, I write regularly about growth engineering, product strategy, and the systems that drive results. You can find more of my work on this blog or connect with me on LinkedIn.