Shipping can cost more than the second-hand item itself, and Vinted's testing showed that price is exactly what makes buyers choose a fast-fashion alternative instead. Having negotiated carrier rates as low as they would go, the marketplace decided the only way to keep lowering shipping was to become a carrier itself, moving from a mature, data-driven app into warehouses, lockers, fleets and robots.
Aiste Miskuniene tells the story of Vinted Go, and the lessons of building physical product inside a cautious software culture. The team learned to match their process to their maturity: build fast with tunnel vision when there are no users and mistakes are cheap, then shift to hypotheses and A/B testing as the cost of being wrong rises. She's candid about the misses too, from conveyor belts defeated by creatively packaged parcels to a costly routing tool an engineering director out-built in two evenings with AI.
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Hello, hello. Very excited to be here. I'm so happy there were so many hands raised, so I will skip the context slide. But yeah, today I will tell you about Vintet's journey into logistics. Why did we decided to go there? And how did we build the product and then mature the product throughout this journey?
So still a bit of a context, what is Vintat for those of you who don't have the app on the phone? So is a CTC marketplace. We started as the marketplace for secondhand fashion, but now we're also venturing into new categories like electronics, furniture and so on.
And it's been quite an interesting journey with Vintage already. We are present in twenty three markets. We became profitable last year. Our growth is thirty six percent year over year in terms of the revenue, and we have more than two thousand employees, so quite a big scale up already.
And we still believe that is just the beginning of the journey. So why Vinted, a C2C secondhand fashion marketplace, decided to venture into logistics? Let me take you to twenty twenty two and how Vinted looked like at that time and what were the challenges that we were facing.
So Vinted at that time is already a pretty large organization. We have cross functional domains. Remember the triangles that Paul mentioned? We have the rectangles. Each team is consisting of engineering, product, design, and data. We structure the teams into domains. Each domain is responsible for their own part of the product.
We have multiple domains, more than ten domains at that time, so like five hundred engineers. Shipping at that time is just one domain with three teams, so a pretty small one. And overall, the product design and development cycle is pretty mature. We have tens of millions of users, so we cannot just go and risk it.
We are very conscious and very careful about how we release the new features. So, single feature has to be, at least the bigger one, to be AB tested. We look at how it's impacting the metrics, and then based on that, based on the data we are measuring, we are making the decisions.
So all of our decisions are data based. We gather a lot of data, and then of course all of the features, bigger at least, have to have the hypothesis. We track the impact and so on. So all of the cycle is pretty well managed and pretty sort of careful.
Shipping is still part of that, so we are still doing all of the data driven decision AB testing and so on. And what does shipping, this one domain of free teams do? They are responsible for connecting the European markets through integrations with different carriers.
So in each of the market that Vintage is present, we have multiple local carriers that you know, like DPD, DHL and so on. So we have integrations with all of these carriers. And then some of the carriers are international, but some of them are local, consisting just within the local market like local posts.
So we connect those local players into one big platform, so that we would enable our users to sell and buy across Europe. So this the domain of free teams are basically taking care of all of these integrations and the user experience of shipping.
Throughout the years, as Vintage grew, our volumes grew as well. And what we did with all of our carriers that we integrate with is we have negotiated down the prices. So naturally, the more volume you give to the carrier, the lower the price.
We have tiered pricing. So all of those negotiations have been going for years, but of course, naturally we hit the ceiling where no matter how more volume you give, there is just no more margin to shave. So we are left with a shipping price that was actually small, but not enough.
And why was it not enough for us? So this is just a picture I searched on Vintet for a unicorn t shirt, And this is the checkout screen that the users would see. So you can see that the t shirt cost four thirty eight.
Then we have on top buyers protection fee. This is sort of an insurance to the users in case they get the item not as described, but it's also our platform fee that we live off. Then we have the shipping cost three twenty five.
The t shirt that I found was from Poland, so it's a bit more expensive on the shipping. So what you see is that on top of the item price, have seventy four percent shipping price. And this is a decision moment for the user.
Do you buy a second hand t shirt for eight fifty five, Or do you buy a new one for ten or eight from a fast fashion retailer? And we have tested the price elasticity for for our users. And what we have seen is shipping price is a big big factor in this user decision.
And the more we lower the shipping price, know the bigger the amount of transactions is. So people are actually buying secondhand way way more often, the lower the shipping price. That's why this was very very key moment for us. We realized we don't want to touch buyers protection fee.
This is what the company is alive for, But the shipping cost, this is what we can play with. And this is the key thing that we need to innovate in and to lower even more. And as mentioned, all of the negotiations have brought the shipping price to a certain point, but it's not possible to lower it even more.
So we decided, okay, so we need to use all of our knowledge about innovation and technology. Being a technology company, we can do more. We can do it faster, cheaper, better. We can innovate and we can lower the shipping price to our users and we can connect the entire Europe.
Don't quote me on this, but in the very initial ideas we said one euro shipping across Europe. It's not necessarily that we will ever reach it, but this was sort of the North Star in twenty twenty two. So we went ahead and did it.
We launched the Vintage Go as a carrier, as a shipping company. In twenty twenty two, we are currently present in France, Belgium and Netherlands. And we are launching Spain and Portugal this year. We have launched a out of home network, which means that we are not delivering parcels home to home, but we are delivering parcels to the what we call PUDO, pick up drop off point.
And we have two kinds of pick up drop off points. So it's either a locker, the blue one that you can see here, or a shop. A shop can be any corner shop, any grocery store that you already have. Usually they have a bit of a spare space in the back and they use the space to store the parcels for the carriers.
So they act as sort of mini post offices for other carriers. So we have expanded our PUDO network, and as a real carrier in logistics, I'm very proud of the debate, because coming from technology company, this is a real world stuff. This is what you can touch. We have warehouses. We have fleet.
We have automation in the warehouse, robots and all of that. And being part of Vintet also means that we are very conscious about environmental impact. So when creating the logistics branch of Vintet, we also made sure that we have that in the core of our strategy.
So small things like fleets, our fleet is fully electric. In the bigger cities, especially in the centers, we deliver parcels with cargo bikes. So all of that is already built in. And of course, the core model of being out of home network instead of home to home deliveries, we are saving hugely on CO2 impact.
So why, so how did we kick it off? How did we build the product? And how the product development changed and mature throughout all of this journey? So again, the context is that we are part of large tech organization. We have this very well controlled delivery and development model.
But now we need to launch something very fast and launch something in the real world, not just an app, not just a website. So yes, we had to build a lot of things in the very beginning and build them fast. So Vintage Go is born in twenty twenty two January.
At that time we only have the business case, So an Excel spreadsheet that shows how everything is growing exponentially and we need to fulfill that. It was decided that we will launch Vintage Go carrier with the first parcels actually traveling through in June twenty twenty two.
So we have four months to build the lockers interface, to build the driver's app because drivers need to drive around the lockers and service them. We also need an admin panel for warehouse operatives to look at the parcels flow and journey and all of that.
Then in April twenty twenty three, next to the lockers, we launched the shops. So we need apps for the shop operators. September twenty twenty three was our first big volume peak. So in Vintet, a bit different to other e commerce's, volume peak is actually in September when the people come back from the vacation but also the seasons change.
So there is a big peak. For that peak, needed to already go from manual sortation to automation. Then in April twenty twenty four, we launched what we call open network. So basically the locker space that we have, sometimes we are not fully occupying all of the cells in the locker, so we can rent it out to other carriers, so that other carriers don't have to put their own locker next to ours, but they can actually reuse the infrastructure that we already have.
And then September twenty twenty four, more volume, more warehouses. We need more automation. We go with robots and then plan for July is even more robots. So the first example of our first steps into this journey of you know launching the carrier and how product development evolved.
January twenty twenty two, we have three teams that are doing all of the integrations and we need to launch a carrier within four months. One team raised their hand and said, we'll do it. We will abandon all of the integrations. We'll transfer them to another team. We want to launch this.
We'll figure it out. So it was a team of like six developers, PM, data designer and engineering manager. And we said, yeah, go ahead. You have full freedom to make the decisions. Launch it by June. Check back you know as often as possible if you have questions, but the key moment was freedom to the team to make the decisions, cut corners when needed, move fast but launch something that we can actually use on on day one.
So what they needed to build, they needed to build the lockers interface. So the screen that you interact with in the locker, all the flow. They needed to build the driver app, they needed to build the sorter app, so in the warehouse you need to sort the parcels, you need to scan them and then to build the admin panel.
Did we do a lot of discovery? No. We didn't have time. What we did, we invested maybe two weeks into architecture design, but more in a sense that we wanted to build something that is a bit more future proof and can scale, so that we don't have to rework the architecture in couple of months.
But we didn't have time to do a lot of benchmarking and looking at what's in the market, what flow is the best. We also had a lot of limitation with the hardware in the locker and with the flows that we already provided by our hardware providers.
So we had to play with what we had and the time that we had and used a lot of just common sense of what we think will be needed and just get something out of the door, something that will be functional and and something that can be used instead of really really polishing it.
So yeah, and we launched our first locker in June twenty twenty two. A year later, we already thought that we are more mature companies in terms of how we use data, we have accumulated a lot of data. And it was just before our first autumn peak, business came to us and said, we need a rerouting solution.
What happens is when the parcels getting dispatched from the warehouse, drivers picking them up and then distributing to the lockers, some of them come back to the warehouse because shop is closed unexpectedly, maybe you know the locker is not functioning or full and so on.
So we got a little bit of parcels back and it wasn't sort of a big deal. We knew that this is happening, but the business says, look we are preparing for the peak and what will happen during the peak is that the more volume come in, the more volume comes back.
And then suddenly we have this you know backlog of parcels just accumulating in the warehouse and we will not able to cope with that and we will get stuck. So we need a rerouting solution. If a driver comes to the point and the point is closed, let's reroute all the parts, parcels to the next available, closest available point.
And being you know all product oriented and data oriented, we were like, okay, so let's look at the data. What is data telling us? What will happen if we implement this solution? We looked at the data and data set. There will be no significant impact to the delivery time and there will be a negative impact to the user experience because users will get their parcels where they don't expect them to be delivered.
So we know that business wants this, so let's maybe be a bit cautious and maybe let's implement a little bit of that, but very safely. Let's test it out. So we spent about two months playing with it and business got impatient and they said, look you don't have anything, you don't have the functionality now, let's not iterate and play and you know be cautious, let's deliver something, let's have the functionality ready for the autumn and then let's iterate.
Then let's play on the user experience and all of the risks and so on and so on. So iterate later. So what we did, we did a wrong choice of you know getting too mature too early and also we didn't anticipate how you know, how business looks at the risk appetite.
They were very open to having quite a lot of risks at that time and coping with the peak instead of being you know a bit more cautious and AB testing everything. So that was a lesson learned for us. And what we were actually going through is we were going through a curve where in the very beginning you have a very high certainty of what you need to build.
So the green line shows how over time the certainty is at the beginning very very high. You don't have anything. You just need to build stuff with tunnel vision, full speed ahead. Just build it, iterate later and then iteration happens later on once you no longer are so obvious in what to build.
And then what happens with the cost of wrong decisions? In the beginning you have zero customers, zero users. So if you screw up, no one will notice. So you can build very fast everything that sort of makes sense to you and then once you know once you mature as a company, get more users, the cost of wrong decisions goes higher and the certainty of what you need to build goes lower and this is where you need to start looking at the data, this is where you need to do user research.
This is where you need to actually iterate in small iterations and figure out how to now nudge users or how to impact your flows and so on. So this is what we were actually doing. We were building full speed ahead in the very beginning without thinking a lot.
Then we started iterating, finding the you know the small improvements and then finally we are at the stage not with all the products, but at certain with certain products at the stage where we use hypothesis, we use metrics, we use impact assessment, we use AB testing, we do a lot of experimentation.
So this is our last experiment from a month ago. This is an experiment on how to nudge users to use a smaller compartment size in the locker. The problem that we have is that users, when they try to drop off the parcel at the locker, they usually select a larger compartment size than needed.
It's of course more convenient for a user to put it into a larger size compartment than try to squeeze it into the XS. But for us it is a problem because we have limited amount of those large compartment sizes in the locker and they once they are filled, are not available for those who actually come with a bigger parcel.
So what we try to do is we try to nudge the user to select the smaller compartment size. For that we used AB testing, actually it's ABCD testing because we have four variants. Variant A is as is at the moment, we just show different sizes and user select.
B and C tries to nudge users to use XS first by this green highlight. And then D is actually once you scan your parcel, it just automatically opens up the XS compartment and then you try to put it in. If it's not available and if it's not fitting in, then you get the option to choose the bigger one.
We failed by the way this experiment because B and C did not have a significant impact. D had a very big significant impact, positive impact but it also doubled the CS calls, customer support calls. So now we're going back to the drawing board and we are reiterating and we are looking at how to be more informative and how to lead the users through this process a bit more clear than we have at the moment, But this is just an example. Now we are using the data.
Now we have a lot more users. Now we, you know, mistakes are more costly for us. So now we have to be cautious. But also now we don't we don't necessarily always know how and what to build. It's not no longer so obvious.
We know what we want to achieve. We don't know how do we achieve it. So we iterate and we test it and you know we have a lot of variants. So now we are getting into a bit more maturity. And during this journey of maturing the product, we also as all of the companies had to make a lot of buy versus build decisions.
And we made a lot of those buy versus build decisions as well. Not all of them were good, and when you have the buy decision that is not good, usually have to go back after a certain period of time, realize you make it you made the mistake, and then either rebuild it yourself, buy something else, but in our case it was mostly innovate.
So one of the examples is conveyor belts. In the warehouse we started with manual sortation in the very beginning, but then when you know the peak period started, we realized, okay, we need conveyor belts to speed up the process. There are a lot of conveyor belts in the market, a lot of carriers use it, a lot of manufacturers use it, not a new thing.
We thought, okay, so we will buy one. Our conveyor belt was slightly different, so it had to go on an incline because at the end of it you have pallets that the parcels need to drop off. Pallets are quite high, so you just need to bring those parcels up a little bit, not a lot.
We bought the conveyor belt with an incline and the reality hit us. This is a picture I think from like two weeks ago. What happens? We had an idea of a very nice, you know, square boxes as in the picture because all of the conveyor belts are mainly designed for b to c or b to b, where the parcels are packaged by manufacturers, by stores, so in very nice square boxes.
Our users are very creative with their packaging. So and we love that. Like, they use reusable packaging for their second hand fashion items, which is awesome. But for us, it's a bit of a problem because they are rollables. They are sometimes very light.
They are sometimes, you know, just a envelope with like a very small item in it. So it's difficult for us to, you know, to weigh them, to measure the dimensions. And also this particular example is very often. So we decided, yeah, it was a wrong decision. Reality hit us.
So we need to rebuild. So rebuild we did. Instead of the incline escalator, we decided, okay, so we need something that will prevent parcels from rolling. We need something that would enable us to sort parcels that are very light, very small, and we went with the yellow robots that you see.
But also we wanted to do a bit more of the automation and lower the price even more. So we also decided to go with robots that can move pallets, that can move bags. So much as possible automate everything that happens in the warehouse.
But what happens is that all of these solutions, they are not very common in the market. C2C is a bit of a rare solution space and rare problem space. So we have to buy bits and pieces of technology and then combine it into one platform.
So yes, we have the robots, but we actually need two stores of the robots because we have a lot of points that we sort into. If we have robots in two stores, in two platforms, we need an elevator. Elevator is not a thing with these robots.
We need to buy one. We need to figure out how do we transport those parcels between the two stores. We need dimension scanner. Dimension scanner is easy on a flat surface, but in a small bowl, dimension scanning suddenly is a problem. All of the robots that move pallets and move bags, it is a standalone solution in the market.
It's not a solution that works with our sortation robots, the scanners, you know, with all of that. So while the parts of the solution are existing in the market, the joint solution and the orchestration of it, it does not exist. So this is what currently we are building.
This is what currently we are focusing on and we hope that we will release it pretty soon. Another buy versus build solution that was not good for us was routing solution. So in the beginning, as mentioned, we released the driver app. Drivers, they pick up the parcels from the warehouse, multiple bags, and they need a route clearly shown.
These are the twenty two stops that you need to complete. This is the time, estimated time. We thought, okay, so we are not alone in the market sorting out this issue. There are multiple companies that work with routing. There must be a ton of solutions that are very mature, very well working.
So we bought one of those routing solutions. Unfortunately, one thing, it was very costly. So for us, as we are aiming at very low price for the shipping, that was a bit of a problem. And then also it was not working as expected all of the time.
So sometimes we would get a route where twenty two points are very neatly packed into one area and then one point is an hour away. So our drivers would not even finish those routes because they would run out of time. So that was a bit of a problem and we thought, but you know what can we do?
This is a mature product. How do we go about this? And actually, one of my engineering director just spent two evenings with an AI, and he developed a solution that was performing even better. We tested it a few weeks back in in real life, a few weeks, and it is performing way better on all of the parameters.
So for us, it was an moment of, okay, so actually even though we have this product that has been built and matured over the years and it's sold as you know, a very, very standard and very sophisticated solution. Actually, we can build stuff into evenings that is for our case performing better.
So having that mental shift of, oh, we can actually you know do that. We can actually do that very quickly and very cheaply and very fast. So that was was another learning point about bad buy decisions where you have to actually redo them and redo them yourselves.
So key takeaways. How did we go about this journey? So first, we just started to build and I think for me, one of the learning points was try not to get ahead of you in your maturity, especially for us being part of Vint at this large organization that is very data driven, being not too fast ahead of you in in data driven decisions was a challenge and still sometimes is a challenge because we, even to this day, we constantly launch new things and then we have this debate of
do we launch an MVP? Do we launch something a bit more sophisticated? We have all of this data available. Let's do a proper discovery and benchmarking and all of And sometimes we do, but sometimes we don't, and this is the thin line of where you need to decide how much into the data and into the details you need to go when you are launching something new.
But for us, first it was let's build a lot of stuff as fast as we can, and you know as MVP as we can to have something in place. And then iterate and then polish and then scale and then see what works, doesn't work and how you you know, maybe you cut some corners that you shouldn't have.
And then the third thing is mature, innovate, go back to those buy decisions that you did in a rush. Maybe it's not working for you and it's important now to realise how much we can do with AI and to challenge those solutions that have been in the market and actually rebuild them very fast and very specific to our case.
