Recently, I changed jobs and went from being an E-commerce Manager to now being a Product Manager. I suspect other people have made or is considering making the same transition, so I wrote this post to continuously share thoughts, and lessons learned.
In mid-2019, after finishing my Master’s, I joined a danish jewelry company named Camille Brinch Jewellery. As employee #3, I was tasked with owning the e-commerce experience, tools & tech stack (“Head of e-commerce” was the fancy title we came up with).
Before that, I’d worked with products in SaaS, with paid ads as a freelance marketing consultant, and in various startups and multiple fun (but failed) projects.
I like to think my competencies live at the intersection of growth, analytics & tech. If yours overlap in some of the same areas, I think you would find my thoughts below somewhat valuable.
Deciding to make the switch
Just before Black Friday 2021, because of various reasons, I decided it was time for me to look for the next adventure. I then took some time off (some of it in quarantine, thanks covid) before I started my new position this January.
When I started reaching out to people from interesting companies, some of the considerations I had were:
Do I try to stay in the e-commerce sector or do I look for exciting things in software or consulting?
Do I look for smaller companies where I can lead and apply learnings or do I look for larger companies where I can grow and learn from people a lot smarter than me?
Based on these thoughts I tried jotting down some basic notes of what I liked and disliked about working with software and did the same for e-commerce and consulting.
Core Differences: E-commerce Manager vs. Product Manager
Before I talk a bit more about each of these, I should say that I think it’s possible to find people with these two titles in different companies that are doing the exact same work. The organizations may differ in size, but people could potentially be doing a lot of the same work.
Stage of hiring
As an early E-commerce Manager, some of the things you’re also entitled to do are creating and managing product information. Given the size of companies when they hire their first E-com person (which I would argue is often the E-commerce Manager), there’s no one else to handle those tasks.
In addition, creating marketing-related landing pages and managing content on the commerce platform also lands on your table. As such, you’re very much a part of running the day-to-day business.
The core problem here, at least as I experienced it, is that there’s generally very little time to THINK. Day-to-day business is a lot of ad-hoc tasks and doing things that are due now or the next day. Campaigns are often planned in advance, but the sort of “maintenance work” an E-commerce Manager does is very rarely planned ahead.
Now, a Product Manager is a much later hire. Usually, there are multiple engineers associated with the team where you’re deployed. As an effect of that, you're not the one taking part in building. You're THINKING. Something I’ve come to learn that I enjoy quite a lot. Someone spending more time thinking makes great sense. Ultimately, because you’re part of a larger setup, the output of your time spent thinking has a greater impact on people’s time, positive or negative.
Escaping the hamster wheel
One of the things I became exhausted of with E-commerce, which was highly caused by the heavy involvement in day-to-day tasks, was the so-called hamster wheel feeling. Because most E-commerce D2C business growth is highly driven by discounting and gifting seasons, events like Black Friday and holiday sales drained me of energy.
The workload, looking across an entire year, is very much uneven. On one hand, it's great because there are clear low-peak months during the year where you can focus on building. On the other hand, the high-peak months are truly high-peak. And if you're part of a growing business, the expectations and risks keep rising year over year.
Software development, I view this much more as a less busy way of taking small steps at a time, building on what you already have, and making it better. I'm not saying it can't be busy, but it's an entirely different way of being busy.
I think the overall cause of the differences here is how your role is involved with things like campaigns during the year. As a Product Manager, you're expanding on and improving the product. As an E-commerce Manager, you're both expanding on and improving the commerce experience, but you're also very tied to the campaigns being run.
Talking to users and customers
One of the things that I did very little as an E-commerce Manager was talking to customers. If we're being rude, E-commerce is often thought of as simple lists of products that people can buy. As consumers, we know how that works. There's a frontpage, a category page, a product page, a cart, and a checkout of some form.
I think user testing is neglected for that reason, but looking at it from a bigger perspective, it might not even make sense either way. If the purchase journey is much like users would expect it to be, there are other areas worth investing in for better differentiation. D2C businesses might be more likely to differentiate themselves through creative content, unique customer service experiences, or stellar product unboxing.
In software, two solutions rarely work the same way. This makes it more difficult to understand how users see and interact with it. As such, user interviews and user tests are much more needed.
As I write this, one of the things I’m focusing on is figuring out how we can continuously talk to users. After doing pretty extensive user interviews and testing, I now understand how users feel, what problems we can solve for them, and where they are troubled with our product.
Building a system that will allow us to have a direct connection with our users and ensure that we can continue to get their feedback is the most important element of the product development loop. Otherwise, it's easy to fall into the trap of building what's "logically" next in line.
Using the output of the user conversations, along with inputs from a bunch of other sources, and our development framework “Shape Up”, I’ll then spend a lot of time pitching the rest of the team what to build in our upcoming development cycles.
Building software vs. selling physical goods
Over the past few years, there have been countless times where I’ve compared selling software to selling physical goods. Before I went into e-commerce I thought it was so much more work than selling software. “There are probably few repeat purchases and no sexy MRR” was what I was thinking, and having to actually ship physical goods sounded like a nightmare.
Now that I’ve been in e-commerce for a bit over 2 years, I’ve realized there are just as many upsides as there are with software businesses. One key upside is that because you’re selling physical goods, it’s much easier for the customer to understand what you’re selling and acknowledge how it provides value to them.
That’s often much harder to do with software…
And although revenue isn’t recurring, it’s still very much predictable.
One of the things I’ve been heavily fascinated by from my previous work in software is the idea of the flywheel. The idea originates from the book “Good to Great”:
Picture a huge, heavy flywheel—a massive metal disk mounted horizontally on an axle, about 30 feet in diameter, 2 feet thick, and weighing about 5,000 pounds. Now imagine that your task is to get the flywheel rotating on the axle as fast and long as possible. Pushing with great effort, you get the flywheel to inch forward, moving almost imperceptibly at first. You keep pushing and, after two or three hours of persistent effort, you get the flywheel to complete one entire turn. You keep pushing, and the flywheel begins to move a bit faster, and with continued great effort, you move it around a second rotation. You keep pushing in a consistent direction. Three turns ... four ... five ... six ... the flywheel builds up speed ... seven ... eight ... you keep pushing ... nine ... ten ... it builds momentum ... eleven ... twelve ... moving faster with each turn ... twenty ... thirty ... fifty ... a hundred.
Then, at some point—breakthrough! The momentum of the thing kicks in in your favor, hurling the flywheel forward, turn after turn ... whoosh! ... its own heavy weight working for you. You’re pushing no harder than during the first rotation, but the flywheel goes faster and faster. Each turn of the flywheel builds upon work done earlier, compounding your investment of effort. A thousand times faster, then ten thousand, then a hundred thousand. The huge heavy disk flies forward, with almost unstoppable momentum.
This, combined with the ideas presented in “Atomic Habits” about the mechanics of small frequent actions and compounding growth, formed a lot of the beliefs I have about long-term business and product growth.
Joining Truestory as a Product Manager
After much research, long talks with people from different companies, and a lot of debating with my girlfriend, I decided that I was going for the move that involved finding a slightly bigger company with leaders and managers that I could learn from. Luckily, Truestory had an open position as Product Manager and I was fortunate enough to land that.
Truestory is a danish marketplace company that sells a carefully hand-picked selection of experiences currently across Denmark, Sweden, and Norway. We’re 40ish people in the company as I'm writing this, some mostly at the office, others fully remote.
Since the company is a marketplace, there’s no product inventory and so "product management" is solely focused on the software that powers the marketplace. My job will be to help grow that marketplace in terms of general usability and user experience.
What it's like working at Truestory
Truestory isn’t necessarily unique in the way the company does things, but there are a couple of pieces of the puzzle that I think are key ingredients in building software and a company “the right way”. For one, it's a truly calm environment where people respect each other's time and focus. I'll explain a few other key parts below:
The development framework
If you haven’t read about how Basecamp develops software, I highly suggest you do so. There are plenty of development frameworks out there, but this one goes further than just describing how code should be written. It’s also about how to work effectively as an organization. If you read it, you'll clearly understand what I mean by saying that I spend much more time thinking now.
Truestory has adapted a form of OKRs, a framework for settings ambitious goals across the entire organization and focussing on objectively reaching those goals. Together with the flywheel methodology, this ensures that we as a company are working in the same direction, which is an awesome feeling if you've never experienced it like that before.
Spending time where it matters
Few meetings, focus on deep work, and as few distractions as possible. Best way to describe it is that the headcount feels lower than it really is because most people are heads-down in their own work and not disturbing each other.
Continuously making small improvements
If everyone focuses on making small improvements each day, those will compound over time. This is where the flywheel methodology applies. Collaboratively pushing the wheel in the same direction, no matter the team or individual.
Get new posts in your inbox
I rarely post new stuff around here, but when I do, I let a selected few know. If you'd like to be one of them, enter your email below.