In my previous post I wrote about our preparation for #BCX2018 hackathon using Sprint approach.
Long story short, we picked a challenging goal — To improve the safety of connected cars by providing a tool for instant communications of nearby drivers, as fast as a horn or a headlight blink.
Then we brainstormed, sketched a lot, and voted for the final vision of the solution.
But as one can’t show something pre-made on a hackathon (though, some hackers still try to), we took a pause and left the following Sprint phases to be completed during the event:
According to the book, prototyping tools should be rough, fast, and flexible. But one can’t win a technological contest by only showing a presentation or as little as a Marvel app prototype. It’s for hackers, right? So, as we had to show something really working, we focused on developing a real mobile app with minimum required features only. For the beginning, without any value-adding (but risky) handmade telematics devices, minor user flows, etc.
Instead of five classic customer interviews in a quiet room, we decided to use judges and conference attendees to test our prototype on. All of them were industry experts, and their thoughts on our product could have been really helpful. Even more — winners would have pitched their ideas in front of 3500+ Bosch professionals from the main stage. Awesome! A winner every time.
Road to Berlin
The capital of Germany is unarguably among the EU leaders in the field of startups, innovations, and governmental (and corporate) support of both of them. They have remarkable technological events running every week, and Bosch Connected World was one of them. I must admit, the venue where it took place — Station Berlin — has a perfect central location right beside Technological Museum and a beautiful park that I had to cross every morning on my way to the venue (actually, I spent there only 2 days, but it was enough for the first impression).
We had prepared two things at home before we went to Berlin:
- A clear vision of what we would be building, including user flows;
- Design sources from Invision. It’s a very useful pack of generic design patterns for any occasions — mobile, tablet apps, websites, etc. These patterns save much time for non-designers (like me) when we need to assemble screens for a pet-product or a hackathon prototype.
At the venue
We weren’t lucky to hear any kick-off speech from experts of our Connected Mobility Challenge (either I was a bit late for the beginning or it didn’t happen at all, as other participants said). Anyway, we were happy to have performed the most challenging idea generation Sprint steps in advance — it made us feel confident (af) when everything around was (or seemed to be after jetlag) unclear and nervous.
Actual app design
I spent the first night combining Invision design patterns to fit our desired user flows, and drawing missing elements:
As we wanted our users to keep safe and focused on driving while speaking to each other, we needed in-vehicle infotainment system integration. Bosch MySpin SDK was offered by event organizers in order to get the mobile app working on the vehicle’s display. Okay, luckily they had 60+ pages of clear SDK documentation, and developers support right at the place. I must say, cars for testing the display connectivity were also awesome: 911 GT3 RS, and two F-Paces (gas and hybrid) with 7’’ IVI’s.
There was one small pivot we took in order to please hackathon sponsors even more: we decided to use Mapbox SDK, and let the car owners talk ONLY if they are on the same route right now. Thinking of real business, we were obviously narrowing the user base and decreasing other usage metrics… But wait! It’s a prototype and two days of fun… Why not?
Hacking log (roughly)
– Telegram API research.
– Telegram client assembly and debug;
– Messaging, chat actions;
– Voice recognition;
– MySpin SDK research.
– Mapbox navigation;
– Profile screen with primitive scoring;
– Final presentation preparation.
We were literally the first to come and the last to go home from the venue. Of course, some guys came with a kind of homework and were happy to go to a pub after 19:00. Good for them. We were going to win in a legitimate way and worked from 9:00 to 23:00 to make it by the end of Day 2.
We were proud of having finally made it work! Both on smartphone and in-vehicle head unit. BUT with several nuances:
– Speech recognition worked, although semantic analysis worked poor with random sentence structure;
– It worked with the limited number of users only;
– Driving scoring kind-of-worked. Frankly speaking, it was an absolute fake.
The presentation was short and focused. I even trained my speech well.
As for me, judgment is very important — it defines good hackathons from average and bad ones. It’s not that easy to evaluate and normalize efforts and results of different-sized teams working in different areas. There exist a few effective techniques of decision making for judges on huge hacker events. A good example is Junction Hackathon — they pay much attention to transparent and fair final votes.
At #BCX2018 there was no judgment (or any kind of technical audit) of projects, unfortunately. You know, every participant (imagine a sleepy hacker after 2 days of hard work) was just given one sticker and could vote for one project (including theirs) on the wall. I personally voted for a random project with «Blockchain» in its description. Neither they are, nor our product won, finally:-)
Despite results and prizes, networking potential of this event was even higher than I had expected. Imagine 3500+ of Bosch employees from all over the world looking for impressive tech innovations. Once you sell something to Bosch, your product will be installed in millions of connected devices — from vehicles to industrial machines. So, it was a good place for building sales and venture relations.
Anyway, for us, the main goal was to show the prototype to potential customers and record their feedback. Some feedback patterns were repeating among the audience:
– App UI was surprisingly simple. Almost nobody failed major flows;
– V2V could disturb drivers because of voice messages from strangers;
– It would be cool to run it on in-vehicle infotainment system, not a smartphone.
I wrote them down for future analysis and made my way back home. Tired, but happy!