I had an interesting conversation this week during an interview about ecommerce growth. The business owner mentioned their marketing spend, which led to a broader discussion about approaches to growth — and then onto how I typically identify blockers and use a KPI-led framework to surface what I call "the good, the bad and the ugly."
At one point I mentioned that proprietary tech stacks can sometimes create constraints — particularly when they slow down experimentation, limit integrations, or create friction in conversion optimisation work. Which, as it happened, was exactly what they were trying to focus on — despite not yet having enough traffic for CRO to be genuinely meaningful.
In the end, it wasn't to be. The owner wasn't sure my approach would sit well with the incumbent developer of the proprietary platform.
But it highlighted something worth writing about: two very different ways of thinking about how to build a growth plan.
Option 1 — Reverse Engineer Around the Current Structure
This approach starts with the existing team and technology, and builds the growth plan within those boundaries. The thinking is straightforward: work with the current developer skillsets, operate within the limits of the current platform, and design the roadmap around what the team can realistically deliver.
In practice, this often means experimentation happens more slowly. Tooling and integrations are limited. Optimisation is constrained by what the platform can actually support. Growth tends to rely more heavily on paid acquisition and incremental improvements rather than anything structural.
The business may still improve — but typically in small, incremental steps. And with a proprietary stack, there's an additional risk: more legacy code and technical debt accumulating with every iteration.
Option 2 — Identify the Blockers and Build From There
This approach starts with the growth ambition first.
From there, you look at what might actually prevent the business from achieving it — whether that's technology limitations, conversion friction, customer experience gaps, product range issues, or operating model constraints. Once those blockers are clear, the growth plan is built around removing them.
That might mean evolving the tech stack, introducing new capabilities, improving processes, or changing how teams operate. In this model, the roadmap is shaped by what the business needs in order to scale — not by what the current setup happens to allow.
Why This Matters for Ecommerce Growth
Real ecommerce growth usually comes from improving the whole commercial system — customer acquisition, conversion rate, merchandising, CRM and retention, and technology that enables fast experimentation. These things interact. Optimising one in isolation rarely produces significant overall results.
When you build a growth plan around the existing structure, you're often optimising within a system that has fundamental constraints. You might improve paid media performance slightly. You might nudge conversion rate a little. But the ceiling is set by the platform, the team structure, and the processes already in place.
When you start from the blockers, you're asking a different question: what would actually need to be true for this business to grow significantly? And then you build towards that answer, even when the answer is uncomfortable.
Sometimes that means challenging the current setup. Not because something is wrong with the people involved — but because removing constraints is often where the biggest growth unlocks sit.
- Are you building your growth plan around what the business needs — or around what the current team and platform can deliver?
- What are the actual blockers to growth — and does your current roadmap address them, or work around them?
- Is your tech stack enabling fast experimentation, or slowing it down?
- Are you investing in paid acquisition to compensate for poor conversion — when fixing conversion would be more valuable?
- Are you optimising incrementally when what you actually need is structural change?
And occasionally, an interview is a useful reminder that not every business is looking for that kind of thinking. Which is fine — but it's worth being clear about which approach you're taking, and why.
