Weekly Wednesday Lunchtime Lectures is an initiative to allow people in Appsterdam to talk about technology and share knowledge, allowing participants to receive training in public speaking. The lectures cover a wide range of topics related to making apps on any platform, from technical to non-technical including computer languages, modelling, testing, design, marketing, business philosophy, startups, strategizing, and more.
Today’s lecture was on
Questionise, a startup that Giwan Persaud, our speaker, is working on together with a partner. They met through Appsterdam. He shares a series of mistakes, lessons and risky decisions in the development of their startup.
The problem Questionise aims to solve is that it’s very hard to show your contribution as a knowledge worker. Your products are usually intangible and hard to see. A typical example of this is working from home: managers often want to see people sit somewhere and be busy, because they know no other way to check whether they are contributing.
In Questionise, you can post questions and answers, which you can use to build a knowledge profile. This exists already, but Questionise also adds activities. This can be used to build a report of what you’ve been doing. It’s a bit of a Twitter-idea, where everyone can see what other people post. Statistics are also public.
1: Not clearly describing the service
Many people who visited the Questionise site did not understand what they were really offering. Regardless of how awesome the product is, if people don’t understand the benefits, they will not sign up. They improved the design and the copywriting, and actively gathered feedback. They’re also working on a video, but this is challenging with the little budget they have.
2: Too much information
Realising they had a problem with describing the service, they initially just added more information. However, this didn’t help at all. People often don’t read text very well. Instead, they tried to reduce the amount of text. But it’s a tightrope: too little text and there’s not enough information, too much text and there is way too much information. The video might help here too.
3: Wasting time with unimportant details
Especially as a developer, it’s essential to focus and prioritise. Otherwise, you might never get to a point where you can offer a real product. It might be better to not fix some bugs or design issues for the time being.
4: Not early enough with landing page
Landing pages help people sign up on the high-level concept. They have a mystery element as well. Even if you don’t know whether you will ever build the product, get a landing page up as soon as possible. If you set it up too late, as they did, you miss out on opportunities. To get people to visit their landing page, Giwan mostly reached out on Twitter, LinkedIn, etc.
There are several services to make landing pages really easy, like Kickoff Labs. Someone from the audience raises the issue that a landing page might get a much higher response rate than the actual product, even though in their example everyone who signed up on the landing page got a free trial.
5: Not focusing on building user base
In a company, there are many different areas to work on. There’s a business plan, a marketing plan, and so on, and they all require attention. However, the most important focus is to simply get users. Every activity must relate to that.
6: Not monitoring the market
They surveyed the market initially, for alternatives and competitors, but didn’t pay much intention on it afterwards. As competitors evolve as well, it would be better not to go in the exact same direction as the competitors. During your development, you have to keep an eye on the competitors as well.
Someone from the audience is an early-stage startup to monitor competition - Giwan and his partner haven’t looked into tools to do this yet. They did find that some users come to them, even though the same functionality is offered by competitors as well, probably because their product is easier to adopt in a business.
7: Not updating the business plan
Giwan recommends reviewing the business plan every two weeks or so. They wrote a plan in the beginning, didn’t look at it for a few months, but by then it was quite out of date. It also helps you to keep track of your strategic direction.
They used the business model canvas, but thought it did not suffice to talk to an investor. Also, their business plan contains much more than the canvas, like financing.
Someone from the audience adds that his experience is that Dutch investors want to know about everything for the next 5 or 10 years. But they don’t know their cashflow in the next 5 years, because they don’t even know what the product will look like in 5 years. Giwan’s feeling is the same, and he thinks it’s a European problem.
8: Platform support: not supporting IE and mobile
Currently, they don’t support Internet Explorer, due to a lack of skills and time. They expect their customers are mostly the innovators and adopters, like startups, which already moved to other browsers. Large corporations use IE very often, but their product is not ready yet for those clients anyways. Although IE 10 is fairly easy to support, it didn’t work out of the box for now, so they just tell all their clients they do not support it.
There is also no mobile interface at this time. This requires development effort, and as they’re still trying to find product/market fit, they don’t want to invest time for mobile yet. On the other hand, it is something that many people pay attention, and the lack of it could hamper adoption.
9: Third-party tools: relying on Google charts
They rely on Google charts in their platform. This is risky, as Google can shut down services. They’ve done this for now, as it does save development time.
10: No fully defined revenue model
Lastly, they have plans for gaining revenue, but no solid defined plan. This would be an issue for investors, so it could turn out to be a mistake. They are working on making this more concrete.
In April, the team at Voradius launched their app–an online search engine that allows users to find products in physical stores in the Netherlands. Available on the web, iPhone and iPad (Android version coming soon), the app is already linked to the inventory systems of 3,500 shops with 50,000 products in Amsterdam, including all of the branches of Kijkshop.
Voradius on the Street
Say you want to buy a particular pair of running shoes. Before you go from shop to shop to see if it is in-stock, the app will tell you which shops in your vicinity have it, how many are left, and the price. Then, instead of ordering it online, you just go to the shop and pick it up. The app also provides general shop information like phone number, opening hours, and location.
Watch the Voradius promo video to see the app in action:
Enter Open Data
Voradius is working hard to create partnerships with retailers to link to their private data and inventory systems. From there, how does public open data fit into the picture?
“We wanted to also provide contextual data for shopping, such as geo-locations of nearby parking garages, real-time traffic data, public transport information, cash machine locations, street activities, and events,” said co-founder Martijn Jansen. “We wanted anything the city could provide from their datasets to enhance the shoppers’ experience going out into the ‘real world’ to do their shopping locally.”
Luckily, all of this data is available, and Voradius has worked with the city to get the right datasets, in the right formats, from the various entities. Navigating this labyrinth can be a challenge, and the Amsterdam Economic Board is connecting Voradius with the local government contacts as they continue to incorporate the data. The act of obtaining the data for Voradius will also help to make it available for other entrepreneurs for future ventures.
For parking information, Voradius is also looking to integrate the Parkshark API from Amsterdam web and app developer Glimworm IT. The API uses open data provided by the City of Amsterdam to find the closest and cheapest parking in the city.
As part of the Open for Business program, Bolot Kerimbaev from Big Nerd Ranch gave a workshop with targeted advice to each group. Kerimbaev worked with Voradius on the database and search capabilities, which form the backbone of the app’s functionality. There’s also the GPS and location-finding aspect to contend with. They ironed out the issues in time for the launch, and they’re continually improving and updating the system as they add more shops to the database.
All three start-ups had a business model workshop with Floris van Alkemade, partner with venture capital firm Solid Ventures. Van Alkemade broke down the details of engaging investors for a start-up.
The Voradius team bootstrapped their venture for 10 months before launching the app, and they are currently looking for funding partners. Van Alkemade explained that without a minimum 100M Euro 7-year valuation, it’s difficult to get investment from venture capital firms in Europe (in the US the expected valuation is even higher). His advice for Voradius was to go for smaller rounds of informal funding from angel investors while they build up their revenue streams, and then look for a larger investment to expand the business to the next level.
The Voradius app is a free download for users, and will bring revenue via a retailer subscription model. The attraction for the retailer is that it increases visibility to customers and creates an additional sales channel.
Launch and Beyond
Since their launch, Voradius has received media coverage in publications such as De Telegraaf and Emerce. The app is quickly gaining momentum, and new shops are being added every week. After establishing themselves in Amsterdam, they plan to roll out the service to other major cities in the Netherlands. It’s an exciting new app, and a great example of using public open data for a commercial business. We wish them the best of luck!
That said, there are a lot of “musicians” in Appsterdam who would quite like to form bands. But as any black-t-shirt-wearing highschooler knows, it doesn’t work very well when six guitarists show up to a jam session. Just as a successful band will need a rhythm section, singer, songwriter, road crew and tour manager, a successful app product will need back-end developers, designers, support engineers and marketing.
So consider this an open invitation: don’t be scared off participating in Appsterdam events just because you’re not an Xcode maestro. I’m seeing a growing realisation among my “lead guitarist” colleagues that killer riffs aren’t enough. The audience needs to be addressed on its own terms and that’s something many of us aren’t the best at. We see the value that great marketing, design and other skills bring and we realise we need help in those areas.
Lots of developers are looking for people who want to be equal partners in building successful products. If you have experience in any of the other skills necessary to bring a great app to life, if you’ve got money to invest in a great performance or if you’re just smart and keen to learn, we’d love to meet you.
“No. I’m not a sound engineer, A&R person, tour operator, venue owner, merch supplier or roadie either… but I’ve got a really good idea for a band name!”
Every app developer has had the above conversation with an enthusiastic but overly optimistic (and possibly misguided) person who’s got a “great app idea and they just need a dev to implement it”. It’s come up a few times at Meeten and Drinken and my preferred strategy is, as gently as possible, to disabuse our hopeful friend of the notion that it’s as easy, fast and cheap (!) as they think it is.
I contacted roughly a dozen rental companies, and asked them:
What happens when your rental bikes are removed by the city? The tourist will probably assume it was stolen.
Does the city notify you when they have removed one of your bikes?
Do you charge the client for you having to pick up the bike?
How does this work when the client chose the optional theft insurance?
I told them I was doing research into the use of bikes by tourists in Amsterdam. For brevity, I did not go into detail about Bike Like a Local - although maybe I should have on second thought.
I received a handful of responses, which seems like a normal response rate. Noteworthy was that some of the companies would only talk to me after getting a detailed explanation of the purpose of these questions and how I would use the answers, or only under condition of anonymity.
Informing the tourist
Most rental companies specifically inform their clients about the parking policy in Amsterdam. The signs placed by the city are all in Dutch (and in my own opinion, not always well placed), and therefore not very helpful.
When a client reports the loss of a bike, most of the rental companies guess whether it might have been removed by the city, depending on where it was parked. If there is a chance that it was removed by the city, they try to call the bike depot to see whether it is there. This isn’t really sufficient, because the opening hours of the bike depot are limited, and there is some processing delay. If the bike is confirmed to be at the depot, the client is typically charged € 20-25 plus the costs of any damage to the bike and lock. However, there are not always able to recover all the costs from the client.
If it is uncertain whether or not the bike was removed by the city and the client needs to leave, the rental companies follow their standard procedures for bike theft. Roughly, this means the client pays the insurance deductible if the bike was insured, and pays the full cost if it was not. Should the bike later turn up at the bike depot, any excess payment is returned.
One of the rental companies also gave some feedback on my plans for Bike Like a Local. They didn’t like the idea for my ad-hoc audio tours, fearing that it might distract tourists and make their biking more dangerous. In the meantime, I looked into that in more detail. They also explained that they do inform tourists about all the dangers, but that they don’t always pay much attention.
On May 1st, I went on a bike ride through Amsterdam with Alkisti and Olga. Alkisti runs Appsterdam Greece and is in Amsterdam for two weeks. At the Design/UX/UI workshop it was suggested for me to actually ride a bike through Amsterdam with a tourist, and Alkisti immediately offered to do this together.
Freeways and tunnels
An issue that had never occurred to me before, is that Dutch people typically say you can bike anywhere in Amsterdam. However, this isn’t true. Although almost all streets in Amsterdam are available for bikes, notable exceptions are some of the tunnels, like the IJ-tunnel, and the freeways, as my guides experienced.
I had somehow assumed tourists would already know where to go in the center, but Alkisti could not find her way from the lunchtime lecture, at Weteringcircuit, to the entrance of the Vondelpark - and she’s already been here for two weeks. Perhaps it’s worth looking into offline voice-based turn-by-turn bike navigation. Currently, when Alkisti plans a route, she makes screenshots of Google maps, as she doesn’t have roaming.
We discussed many smaller issues as well:
There are two common types of brakes on bikes: handbrakes and back pedal brakes. Alkisti is used to handbrakes, but the bike she borrowed had a back pedal brake. This can be dangerous when you need to brake in an emergency.
Alkisti knew how to use hand signals when turning, by copying it from Olga.
The combination of bike and pedestrian traffic lights can be confusing, especially when one is green and the other is red.
I noticed that when the three of us were cycling together, Olga had to look behind her regularly to see whether we were still with her. That could be quite dangerous too.
Tourists from the south of Europe might have Android phones a lot more than iPhones - but I develop for iPhone only.
Olga always teaches people: watch out for the tram tracks, hold on to the handlebars when it’s windy, and watch out for people opening doors of parked cars to get out.
One of them also had gotten a bag stuck in their front wheel before, which is a risk that may not be obvious to novice cyclists.
Although one should usually cycle on the bike path on the right of the road, some bike paths are bi-directional.
Scooters passing in the bike lane seem rather dangerous.
For marketing, I could also look at student information for exchange students, and travel guides.
Overall, it was a fun and useful trip. I’ll have to see how to prioritise all the input, and what I can do with it in Bike Like a Local. Olga and Alkisti also thought it might be good if I do this again with a tourist that’s not from Southern Europe.
On April 27, we had a very productive session on design, UX and UI, with input from experts Joris Hofstede and Li Chiao. This was the last formal session of the Open for Business program.
Initially, I let both experts play with the current version of Bike Like a Local without explaining them much about what I’m aiming to do. I recommend to always use testers this way: never guide them through the app, at least not initially, because an ordinary user won’t have you there as a guide either. If you’re with them as a guide, it’s easier for a tester not overlook confusing or unexpected things in your app.
Both Li and Joris found the opening screen (which is for finding your bike) a little confusing. It just doesn’t make sense if you haven’t cycled yet and open the app. Perhaps a welcome screen would be useful here, but definitely not a tutorial. The text is currently also in the past tense.
Li suggested gathering crowdsourced data for the stadsdelen who are unable to provide me with bike parking data.
Joris thought the artwork for the tips could really use some work. Li suggested to make them a bit less formal overall, referring me to the excellent Dumb Ways to Die video which teaches people to be careful around trains.
The navigation of tips also needs an update. I noticed Li trying to swipe between the tips initially, and only then finding the next/previous buttons. Joris didn’t like the inconsistency in my buttons.
In general, we concluded might be nice to have some kind of reward for discovering things in the tour, or saving where you parked your bike (i.e. checking in). Unfortunately, I can’t integrate Game Center, because Apple does not allow its use for anything but real games.
I told Li and Joris about my plan to have audio tours to explore the city, only after they had a chance to look at the initial app. I wanted to test first whether they also came to the conclusion that the app needs something more interactive, like my audio tours.
Once a tourist parks their bike, it could be nice to offer them tourist information. Particularly about other places nearby, within cycling distance, that they might otherwise not have known about. Perhaps current events too, but this requires connectivity.
We also discussed some ideas for groups meeting up through the app. When a cycling group agrees to meet up in a particular location, it might be nice if there is sufficient bike parking nearby. Otherwise, people might scatter off to find a place to leave their bike, and make it harder to find each other. But this requires some effort to make it work smoothly, and to figure out whether there’s a real problem to solve here.
Amsterdam Like a Local
I also discussed Amsterdam Like a Local with Li. First of all, the button to add new recordings is actually way to small: it needs to become a lot more prominent.
Listening to one of the existing recordings, a new idea we got is to allow people to keep their recordings private as well, and use it as a sort of GPS voice diary. Being able to make a recording public at a later time might lower the boundary of entry. Another interesting feature would be to allow others to make comments on a recording, by making a recording of their own. Asking questions, by using voice, can also be used to trigger more involvement.
We found a few smaller issues as well. Overall, it was definitely a useful final formal session of Open for Business, leaving me with enough to continue working on.
One of the bike rental companies I approached said they didn’t like Bike Like a Local at all, because it can distract tourists and actually make biking less safe for them. Based on a list of research the Ministry of Infrastructure and the Environment provided me with, I looked at possible risks and mitigations in this area.
Distraction risks for cyclists
There are five potential distraction risks involved in using mobile devices in traffic:
physical/motoric distraction caused by operating the device;
visual distraction when looking at the device instead of traffic;
cognitive distraction when the device distracts the user from traffic;
auditive distraction when the device makes sound, and sounds from traffic could be dampened;
effects on moods caused by music or conversation.
The most significant effects are, unsurprisingly, seen in making calls of mobile phones. This is mostly due to the cognitive distraction they case. However, the danger is smaller for cyclists than motorists, because cyclists have more time to evaluate their surroundings. The auditive impact typically plays a larger role with cyclists, because they depend more on audio than motorists. Particularly strong danger is, unsurprisingly, involved in visual distraction, like sending an SMS or reading Facebook.
In around 4% of accidents involving bikes, the cyclist was using a mobile device in some way just before the accident. That could be listening to music, a phone call, typing an SMS, etc. This means 96% of accidents could definitely not have been caused by using a mobile device. Numbers are about the same for listening to music as for being in a phone call, although listening to music is much more common. This suggests the risk of listening to music is much smaller than with phone calls. There also appears to be a discrepancy between perception of risk and actual risk, with the former being significantly higher.
In the debate on whether or not to forbid (handsfree) mobile phone use for motorists, a common argument is that motorists are also allowed to talk to passengers. However, a significant difference is that the passenger is able to adapt to the situation, and change the tempo or complexity. They notice when the driver is busy, or the situation is unclear, and stop talking for a while. With a phone call, the other party does not have such information. This adaption significantly reduces the risk. In addition, low audio quality results in a higher cognitive load. And the passenger can also help reduce the workload of the motorist, by keeping track of road signs, for example.
Regarding music, the type and volume is very significant. For cyclists, the main risk is in reduced auditive attention. High tempo and volume are major factors here. The consensus of all research is that there is the use of mobile devices increase risk a bit, but that there is definitely insufficient basis to forbid their use.
Risks for Bike Like a Local
For Bike Like a Local, the risks are in the cognitive and auditive distractions. There is no interface to interact with, making physical and visual distraction insignificant. And, exploring the city with Bike Like a Local is even less involved than listening to music. Like music, and unlike phone calls, it does not involve the user replying or making decisions, but it’s also not as continuous as music, and will not have a high tempo.
Regarding cognitive distraction, I’m aiming for Bike Like a Local to behave like a car passenger. I want to integrate data about black spots (the most dangerous places in Amsterdam) so that I can warn the user, and make sure the app stays quiet otherwise. This might actually raise their attention level when crossing through a black spot. I’m also researching whether I could reduce the frequency of messages as the noise level increases - possibly indicating busier traffic.
To reduce auditive distraction, I specifically tell users not to use in-ear or closed headphones, and to make sure they can still hear other traffic. If needed, I recommend they only wear one earbud. I’m considering to even force all audio playback to one side only, to enforce the user to only wear one bud. I also want to look at throttling the maximum volume.
In other words, although an app like this can distract the user, research in this field suggests that my features will minimise any distraction. And combined with all the features that improve safety, I’m confident the user will end up saver than without.
Amsterdam Like a Local lets anyone talk for 30 seconds about something they
know about Amsterdam, and tag the recording with a location. They can talk about
a special story they know, or anything else they feel is worth sharing.
On the other side, anyone can
listen to the recording. But, the only information a listener gets are the location
and categories. There are no descriptions or titles. There are no names or
aliases. There is no way to know who made a recording, or whether two
recordings are made by the same person. The only way to learn anything
at all, is to listen, making it a delightful surprise every time.
A big inspiration for this experience is JIRA Mobile Connect, the feedback system I use in all my apps. Among other great features, this allows a user to make a recording and send it to me. It then gets attached to a new JIRA issue. Few people submit recordings, but when they do they usually do not enter a description. So I have absolutely no idea about what they recorded, until I listen. Ever second of audio is a surprise. It’s that same surprise that I aim to bring to other people with Amsterdam Like a Local.
On April 9, all Open for Business teams were invited to Pitch Club. This is an open monthly event where people can practice their 60-second pitch. They then receive feedback from Mike Lee.
I consider myself a decent pitcher, and was one of the winners of the Amsterdam Startup Week / Appsterdam pitch contest, pitching about Openbaar Vervoer. However, there is always room for improvement. And of all my apps, Openbaar Vervoer is probably one of the easiest to pitch, because so many people immediately understand this need.
I was quite happy with my pitch. The challenge Mike gave me was to make it apply more to the audience of the evening, as it was aimed mostly at potential users of Bike Like a Local. This is not simple, but a valid point and definitely achievable. The evening was also a nice opportunity to meet new people.
I did a redesign of much of the user interface of Bike Like a Local, to make it look more polished and professional. I added over 10.000 bike parking spaces provided by Stadsdeel Nieuw-West. I also added a database of contact information and improved some of the tips. I realised I could just release all these updates already, so a new version with these changes is now waiting for Apple review. Release expected about a week from now.
In the meantime:
Amsterdam Like a Local has been rejected twice by Apple. I’ve made corrections, and the latest update is now in review.
The Dutch Ministry of Infrastructure and the Environment sent me a large set of reports about the safety of using music and phones while on a bike. I still have to read it all, I plan to use this to make sure I don’t actually make it less safe for tourists.
I approached many bike rental agencies with some questions about how they handle certain situations, and got a lot of other useful feedback from them as well. Once I have all the replies, I’ll aggregate all their input.
I sent a WOB-verzoek to Stadsdeel Noord and Stadsdeel Zuid-Oost to provide me with the zones where they do strict parking enforcement for bikes, if any, and their bike parking locations. They have ignored previous requests; a WOB-verzoek means they have to reply or eventually pay a penalty.
I asked ATCB whether they have any data on internet connectivity for tourists. Do they use roaming? Do they not use internet at all? Do they buy a temporary Dutch SIM?