Gijs Verheijke

Back to articles

First learnings in Product Management

3 Jan 2021

When Ox Street started, I had a co-founder for about a month. A talented and experienced Product Manager who was going to take care of the tech side of things.

Unfortunately, he got an 'offer he couldn't refuse' from his employer and didn't follow through. That left me as the sole founder, and left me in charge of finding engineers and leading the development of our product.

No problem! I thought my experience with project management and team management in general, as well as my obsession with structure and clear communication left me well prepared. I was squarely at the peak of "Mt. Stupid".

No alt text provided for this image We ended up with a product that wasn't ready for launch, and at the end of October 2019 I made the hard decision to launch with a Shopify storefront and an elaborate set of Google Sheets and Google Forms to manage our supply side. Even at that stage, I thought we were only about 4 weeks away from launching 'the real thing'.

Well, as I crashed down into the "valley of despair", we stayed about 4-6 weeks away from launch until we finally switched over to our own product in May 2020. 7 months later than planned. It's not easy to build a marketplace from scratch it turns out, and product management is a serious job that requires both deep and broad knowledge, as well as both creativity and structured thinking.

Currently, we are shipping a daily release on, and we are the only regional sneakers marketplace with mobile apps.

With our own product giving us full control over the UX for both sellers and buyers, we finally started to get traction over the past 6 months, and now we are processing over 5x as many orders as in our peak month on Shopify, with less than a third of the marketing spend. To be honest, I really love the PM job, and I do believe I have started my long journey up the "slope of enlightenment".

There are endless learnings ahead, but the journey from complete zero to halfway adequate in managing a product, not to mention the satisfaction of shipping a working marketplace across 3 platforms, has been for my personal journey the most enlightening, frustrating and educating experience of 2020.

1. There is a fundamental 'technical co-founder problem'

So much has been written about this already I'm not going to add much to it. If you want to launch a high quality product fast and it can't be off-the-shelf, you need a technical cofounder who is aligned with the vision and can and will code the first version themselves. This is almost impossible to find on-demand for a business founder for many reasons. My summary is: there are #1) way fewer technical cofounders around compared to business cofounders, and #2) they have their own ideas to build rather than someone else's.

2. Find engineers who will talk to you

At the start we had engineers who were unable or unwilling to explain what was really going on. After missing deadline after deadline as a founder, you crave clarity and some agency. I have rarely felt so helpless as when an engineer told me to "just trust him that he would get it done" (he didn't). Later, I found a great engineer who would actually just show me in the code what the problems were. That was a game changer. I finally became aware of the size and scope of the issues we had with some of our core backend services, and it enabled me to become part of the solution instead of an adversary. Communication is probably the Product Manager's most core job, but it starts with hiring engineers who communicate back.

3. The wireframes are wrong, the designs are wrong, and the spec is wrong

If you are the Product Owner, in the sense that you own the user stories and the vision and acceptance criteria for the product, you must really own the product. One of the key things I did wrong at the start, was specifying the user stories and acceptance criteria, and then just leaving it to the engineers. That is not enough. It takes constant alignment to make sure everyone really understands the user stories and what is expected. Also, you need to put in the work to find out where and how the specs are wrong and which cases have been forgotten.

4. Git Flow, Github Flow, branching, merging and shipping

Remember that as kid when you read Donald Duck, you thought quicksand would be a serious danger throughout your life? Shipping and managing merge conflicts was my quicksand, and there was a time in May/June where I was super freaked-out about it. But every real PM I spoke with considered this something that is not even really in the scope of the PM job. They were right. It did not turn out to be a problem.

Why I thought it was going to be a massive issue, is because at the time just before release we had a develop branch that was often unstable, because many different elements were still in flux. Also, there were so many dependencies between our supposedly 'micro services' that often a small change would break all kinds of things all over the app.

After we had a fully featured, relatively stable version of the code, it turns out our develop branch is actually stable most of the time, and since we release (almost) daily, our releases are small and conflicts therefore pretty unlikely.

2021 I plan to continue spending 50% or more on product. One of the benefits of my quantitative background is my obsession with data and measuring stuff. By measuring and tracking conversion through our checkout funnel and making improvements based on that data, we have more than doubled our conversion rate since June. Looking to the future, there has rarely been a more exciting time to have an early stage consumer app in the market.

Ox Street is a leading player in one of the most rapidly growing, passion driven product categories. And placed squarely in the center of the great verticalization / unbundling / re-bundling that is currently happening in online commerce. We need to follow the market, but also transition into shaping our future and defining our space ourselves. Exciting times ahead and we have lots of stuff planned for January.

Resources for Product Management

This is a short list of my personal key sources of learning. I hope others will benefit as much as I have from these:

Lenny's Newsletter: Without a doubt one of the best monthly subscriptions I gladly pay for. This is not just a newsletter providing one person's opinion, but often incorporates knowledge from some of the best companies in the world. One of the best posts is free and you can find it behind the link above.

This git guide: I actually did learn to checkout, modify and merge branches on github. It is really not that hard, and it helped me a lot to understand how it all works.

Intercom product blog: Clear, detailed, actionable. Just great deep content on how to ship a product.

The Mom Test: I would (and have been) recommending this book to everyone who wants to learn to ask better questions and avoid inadvertently asking really bad ones. Absolutely brilliant and I wish I had discovered it earlier.