Four years ago we embarked on an innovation project within bpost, the Belgian post group. You can send parcels through the mail, but what about items which do not easily fit in a small box such as bouquets, ping-pong tables or bicycles for your family trip at the beach? Could we bring these people into contact with drivers who would like to perform these services for a fee? Enter bringr, a crowdsourcing platform for deliveries.
We started the project in January of 2016 and launched an Android and iOS app less than 6 months later in Antwerp. Here’s our story of that period and three lessons on things we could have done differently.
Lesson 1: Get out of the building, embrace it more like a start-up
There are many ways in which you could organize innovation projects within a larger organisation. Our motto was to run things independently where we could and use bpost’s services where convenient. Running our own software in the cloud separate from the main systems allowed us to iterate and launch software much faster with a small team. At the same time it was very useful to rely on the tax and legal expertise of ‘the mothership’. The sharing economy law in Belgium was still being written at this stage, and an organisation like bpost was better positioned to achieve compliance faster than a start-up. Launching the service with the bpost brand in the background and backed up by bpost’s parcel insurance may have instilled more trust in the new service than they might have with a new name on the block; I was stumped people started handing out laptops to strangers straight away.
This may sound like a dream: the speed and agility of start-ups, combined with the process advantages of a big organisation. However, we didn’t entirely embrace the lean innovation mindset as we might have were we a real start-up.
We went to work in the main building and didn’t leave our office space as much as we could have to interact with potential customers and other start-ups in this space. As a start-up, the entire team should have a product and sales mindset and needs to go out there to get the idea known and gather feedback.
The main organisation also has its obligations towards unions and its other services. This impacts how you might do marketing or experiment with pricing. We experienced how it could be done differently with another last-mile delivery start-up, Parcify. On their launch in Amsterdam they released press videos on how their couriers would deliver parcels by kayak in the canals. The start-up mindset ‘to dare more’, may be easier to obtain if you leave the more risk-averse environments. At the launch of the product we settled ourselves near other start-ups in an incubator in Antwerp, which seemed helpful as we were much closer to our early users.
Lesson 2: Launch even faster, and get feedback faster
Launching a new crowd sharing platform in under 6 months was certainly a challenge. We experienced some setbacks along the way (brand-new container orchestration platforms not behaving as expected, stories taking longer to develop than anticipated), but we learned quickly and adjusted the scope of the application accordingly. Initial designs such as the matching algorithm were adjusted in scope through story mapping, as we kept our eyes on the bigger end-to-end picture for a launch in June.
That summer we launched in Antwerp, and sent out promo teams to hand out flyers to shops near the busiest shopping streets. It was at that moment that we discovered an important customer segment, the florists — who typically had to temporarily close their shop to perform deliveries on their own. Bringr was a big help for their pains. We adjusted our marketing and sought out florists where they went (Steven en Leander from sales/business development set up booths at flower auctions at 5 am). Perhaps we could have learned this sooner, had we ‘launched’ with prototypes of which we only partly supported the end-to-end process with software.
An idea that emerged during a retrospective offsite was to start with a Whatsapp group, where customers would ask for their orders through the group and any courier could complete the order (where we could fill in if no one else would be interested). Without having built new software yet we would be able to learn about the end-to-end process and how to tackle challenges such as ensuring a delivery was completed successfully by the driver; and grow a test user base who we could rely on for questions while building the platform. We may have launched the full-software solution later this way, but we would have started gathering feedback much sooner.
Lesson 3: One team, keep tabs on health
I’ve been thinking about this project quite a bit in the recent months. A short while ago I attended QCon (summary here), and one particular talk from Stephen Janaway, ‘My team is high-performing but everybody hates us’, brought back memories and excellent tips. One of them is to measure team health in various categories regularly.
In an innovation project the team deals with new challenges, a lot of uncertainty and everyone takes on more responsibilities than in a usual corporate project. And just as you’re out of the frying pan from a challenging deadline to release a brand new project in the market, you’re dealing with the challenges which come with a sharing economy platform which allows anyone to become a driver or a customer and the resulting disputes between them. At the same time the team is trying to discover product/market fit, there’s the red tape and pressure from the main organisation who’s deciding whether or not to keep pursuing the endeavor.
It’s a lot ot handle, but one of our core strengths was that we were in it together as one team. During development the entire team worked closely together in the same room, after launch the operations and technical team were often physically separated. To bring back the feeling of one team collaborating, we had extended Friday breakfasts (every week someone else does the shopping) where we went through our challenges (be it operations, IT, marketing … ) in an open forum.
We held regular retrospectives as part of our sprint to identify improvements to our way of working, but they were mostly focused on delivery improvements. Something like the spotify squad health model could have been useful. I would add categories to the model such as work-life/balance and sharing challenges together. We may have started rotating the support telephone sooner this way, or prioritize development work to alleviate operational or support problems. Be mindful of the risks associated with the additional pressure and challenges and don’t treat it as just another project. And while you should embrace the start-up experience in your innovation project in order to dare more, not all start-up aspects are worth embracing.
While we could have some things differently, I believe we did a lot of things right and it was an absolute blast with a great team.
If you’re interested in the app, you will no longer find it under the name bringr. A year and a half later in December of 2017, Bpost acquired another start-up in the crowd-delivery space: the aforementioned Parcify. The two projects lived on separately for a while but were merged a year later. But that’s a story for perhaps another time.
Thanks for reading! If you liked this article, you may also like one of the most popular posts: How to make software architecture trade-off decisions or How to get started with Threat Modeling, before you get hacked. or scroll through the history below or on the main page.
Get notified of new posts by subscribing on substack or the RSS feed.