Open application  /  Hears  /  Growth

I am not applying for the CRO Manager role. I am applying for the seat next to it.

You are looking for someone who will partner with design and dev to ship winning variants fast. I am both, in one person. So the roadmap moves at the speed you planned for, not at the speed of the build queue.

The bottleneck

The roadmap is almost never the constraint. The build queue is.

Run a high-velocity A/B testing roadmap across the Hears site. Partner with design and dev to ship winning variants fast. From the CRO Manager posting

That second sentence is where high-velocity testing usually dies. A test gets designed in an afternoon and then waits three weeks for someone to build it. A roadmap of forty tests a year quietly turns into twelve, and the twelve that survive are the cheap ones, not the interesting ones.

At your volume that is not a scheduling problem. Most brands are constrained by traffic, because they cannot reach significance on anything subtle. You are not. You have the traffic to resolve a test quickly, which means the only thing standing between the roadmap and the revenue is how fast someone builds the variant.

I write the code. Shopify and Liquid, Replo, Next.js. A variant does not become a ticket, it ships the same week. That is the entire reason I am writing to you rather than to a role that matches my years.

Straight about the gap

What I do not have

  • Two years under a CRO title. I am 19.
  • A record of won tests with verified uplift numbers. I am not going to invent them.
  • Experience operating at nine figures.

What I do have

  • Three Shopify brands I have built and run funnel work on: store, theme, tracking, retention, ad ops.
  • The ability to build the variant myself, front end and Shopify side.
  • My own internal tooling: a CRM, an accounting app with a live bank sync over the FinTS protocol, generators that produce ad variants at volume.
  • A current view of the stack: Shopify Rollouts, Replo, GA4 and where it lies to you on Shopify.

Operating record

Wake Performance
Shopify  /  live
Launch sprint end to end: theme work, landing pages, creative. I built the measurement on a single axis so that every variant, angle and asset stays attributable, because a decision made on data that cannot be trusted is still a guess.
Hearo
Shopify  /  US
Operated end to end: store, retention, tracking and ad ops. My proof is operational rather than a case study, because I run these, I do not consult on them.
Bachgold
Six figures Shopify  /  seven figures Amazon
I rebuilt the storefront and moved the tracking stack across without losing signal. Last month it converted at 3.23% across 7,202 sessions, up 111% on the comparison period. An external partner runs paid media and it is peak season for the product, so that delta is not mine alone. Earlier, when acquisition cost spiked after the migration, I did not theorise about why. I put the working setup next to the broken one, found the single difference, and only then touched anything.

How I would run it

I do not arrive with a playbook. I arrive with no assumptions.

Every brand converts differently and every creative converts differently. A pattern that worked on someone else's PDP is a hypothesis, never a reason. So nothing gets decided on instinct or on what worked at the last place. It gets decided on your data or it does not get decided.

Week 1
Read the history before having an opinion. What has already been tested, what won, what lost, and which pages actually carry the revenue. You have been testing for a while. The worst thing a new person can do is re-run a losing test with fresh confidence.
Week 2
Clear the queue. Wherever build capacity is the constraint, there is a backlog of variants that were specified and never shipped. Those go live first, because they are already decided and cost nothing but hands.
Week 3 on
Own the build side of the roadmap. Spec to live, every variant. Primary metric, guardrail and sample size fixed before a test starts. Sample ratio checked before a result is believed. No stopping early because a number looks good on Wednesday.
Every Friday
One page. Wins, learnings including the ones from losing variants, next bets. Revenue impact at the top, not the number of tests run.

Two things I noticed on hears.com

Checked on an actual iPhone, not a desktop browser pretending to be one. That distinction is the whole point of this section.

Test
Neither the price nor the add to cart button is in the first viewport on mobile. Promo bar, header, hero image, award badges, thumbnail rail, category line, product name, rating. Then the fold. On paid traffic, a visitor has to work before they find out what it costs.
Test
Free shipping starts at €50 and a single pair is €43. That seven euro gap is presented beautifully in the cart drawer, progress bar and all. But that is after the decision. On the PDP, where the decision actually gets made, it is nowhere in front of the buyer.

I have a longer list. I am deliberately not putting it here. These two I checked on a real device. The rest I have not, and an observation from a desktop browser emulating a phone is a lead, not a finding. I know that because one of mine fell apart the moment I looked at it properly, and it would have been on this page if I had not.

Observed late July 2026. You are running ABConvert, so some of what I saw may be a variant I was bucketed into rather than what everyone gets.

The ask

A paid one year position as CRO execution under Growth at Hears. I run the test calendar, I build the variants, I own the weekly report.

Location
Relocating to Amsterdam
Commitment
One year, full time, paid
De-risked
Four weeks, one deliverable, then you decide