Sprint, Part 2: Bosch Hackathon

Sergey Konovalov
6 min readMar 28, 2018

--

In my previous post I wrote about our preparations for the #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:
- Prototype
- Research

Prototype: Plan

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.

Research: Plan

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.

With the clear plan and need for victory Alex, Nadya, and I started for Berlin.

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).

Station Berlin. Source: Google

Preparation

We had prepared two things at home before we went to Berlin:

  1. A clear vision of what we would be building, including user flows;
  2. 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:

Sending a V2V message
Receiving a V2V message

Technologies overview

The base of our product was Telegram API — a cutting-edge open source messaging app. So, we forked its mobile client (it took plenty of time, but thoroughly fulfilled our messaging demands), and focused on speech recognition and decoding with iOS Speech Kit.

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.

GT3 RS. A masterpiece!

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)

Day 0:
- UX/UI;
- Telegram API research.

Day 1:
- Telegram client assembly and debug;
- Messaging, chat actions;
- Voice recognition;
- MySpin SDK research.

Day 2:
- 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.

Prototype: Fact

Paper storyboard (left) and actual MySpin simulator screenshot (right)

We were proud of having finally made it work! BUT with several nuances:
- Speech recognition worked, although semantic analysis worked poor with random sentence structure;
- It worked with the limited number of users;
- Driving scoring kind-of-worked. Frankly speaking, it was an absolute fake.

The presentation was short and focused. I even trained my speech well.

Judgment

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:-)

Research: Fact

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!

You’ll find even more content, and form for early-bird access to V2V Messenger on v2vmessenger.com. You can also visit our Instagram and Facebook for direct communication with the team.

Thanks for enjoying the post. Please, subscribe not to miss future ones.

--

--

Sergey Konovalov

Product Management: Connected Cars, Mobile Apps, Social Networks