Sprint, Part 1: Shaping the idea of V2V Messenger
The faster we build prototypes, measure their impact, learn, throw away, and build new ones — the greater product we ship to our customers at lower costs. Let me explain.
When planning a new product, one can never really guess what customers will love (and what’s the most important — buy) and hate in the product when it is released. Even if we interview customers in advance (trying to define and prioritize features of the product), their answers may only bring mess to our product roadmap, and additional costs to our budget. They will start to pretend themselves to use our product, not really using it, hence feature requests will be based on dreams only but developed for real-world money.
You’ll never meet a classic “waterfall” project management approach in rapidly growing startups, too — they know that most of their initial ideas may be wrong, and prefer quick hypothesis tests to solid product plans. It helps to keep business lightweight and agile, along with taking pivots just in time, before it’s too late. Learning and changing fast (and cheap) are extremely important skills for a startup.
Sprint explanation
The most hardcore prototyping/testing technique that I’ve ever met is Sprint, it is widely used by Google Ventures team to help other startups shaping their business ideas.
Sprint helps to lead any crazy idea to a viable (and disposable) product prototype, and test it on a real audience in as little as 5 days. The whole process requires: a team of 4–7 internal experts, fully concentrated on Sprint, external advisors, a lot of individual work on prototyping, strict time limits, and potential customers to test the product on. Looks pretty much like a hackathon, right?
Lately, I received an invitation to Bosch ConnectedExperience IoT hackathon. I agreed and tried to use Sprint approach to get ready for it. Below in this post, you’ll find a step-by-step Sprint guide based on my teammates’ and my experience of shaping the initial idea:
“Commuting could be safer, if connected cars and their drivers warned each-other about collision danger, driver health, bad road conditions, etc.”
Disclaimer: All statements and conclusions written in this article represent a personal point of view only, and don’t disclose any of NDA’s signed by the author.
Team
Looking back on the day when I decided to give Sprint a try, gathering the team of professionals, inspiring them with the idea, and keeping focused on the goal all the time was the most challenging task.
Imagine senior mobile developers, and hardware/electronics engineers from banks or automotive companies with their daily routine, overtimes, families, pet-projects, etc. Normally, they are not open to new initiatives that require a few days of intensive extra work, when the result is even unclear in the beginning.
But I’m lucky to have good old friends in Alfabank, Remoto, Telegram, who were glad to join me as teammates, or external advisors: Alex (Mobile), Nadya (Product), Russel (Electronics), Nick (Mobile).
Long-term goal
After the introduction, and a few rounds of discussion our team was lucky to have crystalized a clean, and short statement for the long-term goal:
“We want to create an instant messenger for the safety of connected cars, their owners, and passengers.”
Why?
Existing ways of direct driver interaction for “mid-range” collision avoidance (most of the accidents happen in city traffic, with the speed below 40 km/h) are barely informative, and have lack of feedback: beep, blink, waving with hands. Though, they are really quick and intuitive :-)
According to The Engineering Handbook, Second Edition, 90% of collisions involving 2+ vehicles could be avoided if the drivers were warned in 1.5 seconds before the actual collision. More information would help drivers to make better decisions. In the autonomous era, passengers will have even more time for communicating with each other. That’s why we considered the idea of V2V Messenger viable and worth testing.
Future vision. What’s next?
1 year — Drivers communicate with each other for different purposes. Data is being analyzed (multiple data points: emotions, driving style, car condition, etc.)
2 years — V2V is available in OEM in-vehicle infotainment systems
3–5 years — Switching to driverless cars = more driver’s time for in-vehicle infotainment systems usage, and deeper social networking (enabling more sophisticated safety features)
Sprint questions
Then we got pessimistic, and asked ourselves: “How could we fail?”, and turned these fears into questions to-be-answered during the Sprint. Here’s what we generated:
What if…?
- OEM’s and governments implement an obligatory solution?
- Users are afraid of communications?
- Car owners don’t trust the app?
- Car owners want to be anonymous?
- UX is inconvenient and slow? Beep and horn are faster.
- Users don’t like the way we display information (text, sound, visual)?
- The market has lack of money/monetization is difficult?
- The user base is weak?
(Author’s note: don’t hesitate to add yours in the comments section below, for our next Sprint)
Map
We listed customers and key players on the left. Drew the ending, with our completed goal, on the right. Finally, we made a simple flowchart in between showing how customers interacted with our product.
Expert talks
We spoke about 15 minutes with each internal, and external expert on our initial vision, market demands, production constraints, etc.
Hardware advisor noticed that building custom devices, and making them network with other devices (via Bluetooth) could fail due to inappropriate response latency, hence ruining the idea of road safety. It could not be even close to real-time communication, especially when the object would be moving.
#BCX2018 Hackathon organizers noticed that pre-made hardware would decrease our chances of victory. Though, the actual list of available hardware provided by Bosch was unclear, building a custom one seemed unreal during the 1.5-day event. So, we decided to focus primarily on mobile development, not hardware, and updated our Sprint Map a bit (Device = Smartphone and/or IVI here):
“How Might We…” notes
Rephrasing — It’s always my favorite part of Sprint. We tried to turn problems into opportunities. We put “HMW” in the top left corner, and started generating ideas: everyone wrote one idea per sticky note.
Organizing — We put all the How Might We notes onto a wall in random order, merging similar ideas, and remember to make it fast (<10 minutes).
Voting — Each person had three votes (the number depends on team size, and I can’t tell you a correct number — I think one just need to feel it), and literally put colored dots on the map without discussing anything. The winners were then put on the Map.
Sprint target
The red circle highlights target moments on the map. As you can see, registration was considered trivial, and the most popular HMW’s appeared to be somewhere in the middle of user journey:
Lightning demos
During this phase we took our laptops and started googling for the best solutions from a range of companies on the market, capturing them on the whiteboard in order to use their practices in our prototype:
Waze (Google)
- See people driving to the same destination
- Carpooling
- Build → Play → Monetize
Hyundai Navy (DigiPLOT)
- Collision avoidance
- Recommendations
Mobileye (Intel)
- Car, pedestrian recognition
- Free parking space recognition
- Paths and moving objects recognition
- Signs alarm
- Front impact alarm
- Retrofit / OEM solution
Patent for V2V communications: https://patents.google.com/patent/US8520695B1/en?q=vehicle-to-vehicle
Cadillac DSRC: https://www.theverge.com/2017/3/9/14869110/cadillac-cts-sedan-v2v-communication-dsrc-gm
US Governmental requirements proposal: https://apnews.com/9a605019eeba4ad2934741091105de42
Siemens DSRC Vision: https://www.siemens.com/content/dam/webassetpool/mam/tag-siemens-com/smdb/mobility/road/connected-mobility-solutions/documents/its-g5-ready-to-roll-en.pdf
Car2X Technological Overview: https://vector.com/technologie-tage/files/VTT17_Grundlagenseminar_Car2x_V2x.pdf
Air Traffic Control: https://science.howstuffworks.com/transport/flight/modern/air-traffic-control.htm
European Annual Accident Report 2016: https://ec.europa.eu/transport/road_safety/sites/roadsafety/files/pdf/statistics/dacota/asr2016.pdf
Divide or swarm
As our map appeared not too complex, we didn’t have to divide for sketching different parts of the map. We all focused on the core functionality (Author’s note: please, see the red circle above).
The Four-Step-Sketch
Notes
Quick notes normally take about twenty minutes. Every one silently walked around the room and gathered notes.
Ideas
Each of us generated a bunch of rough ideas and selected the most promising ones in 20 minutes.
Crazy 8s
Eight minutes (the most challenging time limit throughout the whole Sprint, actually). Everyone folded a sheet of paper to create eight frames and sketched a variation of one of one’s best ideas in each frame. Like this:
Solution Sketch
Self-explanatory storyboards containing only three sticky notes on a sheet of paper, with a catchy title, were made by everyone in 90 minutes.
Some of them were ugly (though we still don’t know whos drawings were the worst — they were kept anonymous), but it was okay for that step of the Sprint.
Recruit Customers for Final Test
I must say, that on this step we didn’t follow the Sprint Book guidelines. As Bosch ConnectedWorld Conference would gather 3500+ automotive and industry professionals, we decided to get feedback from them while demonstrating the results of the hackathon in front of the panel of judges and other attendees.
UPD: Check out hackathon log and the app design sneak pics here.
Sticky Decision
Art Museum
We put solution sketches to the wall in one long row.
Heat Map
After that, each person reviewed the sketches silently and put one to three small dot stickers beside every part he or she liked.
Speed Critique
Then all sketches got criticized by the whole group (3 minutes per each). We discussed all highlights and captured important parts. In the end, sketch authors uncovered themselves and told everybody if some details had been missed.
Straw Poll
Each person silently chose a favorite idea. All at once, each of us placed one large dot sticker to register his or her vote.
Supervote
As a decider, I picked the final prototype and explained why I did so. That prototype was exactly what we were going to build during #BCX2018 Hackathon.
Divide Winners From Maybe-Laters
Other promising sketches with votes were also saved for later. But, of course, we understood that there was no chance to fit their development in as little as ±20 hours of coding. So, we fully concentrated on the main goals.
Make a Storyboard
We drew a grid. About ten squares on a whiteboard, and decided which scene would be an opening one. As we excluded Registration step from the Map, on our opening scene there was a registered user willing to start a conversation. We included just enough details in order not to waste time at the hackathon, trying to understand what the frames meant (we used a detailed solution sketch shown above as a base).
Prototype, Research
Author’s note: As the next stages were agreed to be performed at the hackathon, you’ll find more details about it in my next post: https://medium.com/@sergey.konovalove/sprint-part-2-bosch-hackathon-20dc6a363ecf
- Actual app design
- Technologies overview
- Hacking log
- Judgement
- My BCW feedback
Please, subscribe to my posts not to miss a thing. See you soon, and don’t hesitate to share and discuss this post, of course :-)
