The Istanbul Design Sprints: A recollection of 20 startups, four days, and one challenge
When I first heard of the idea on the cafe looking down to the business district of Istanbul with its regular assortment of skyscrapers, I thought it was ambitious at best. I was there for an unrelated reason; and beyond, I wanted to spend some face time with the city I like to call my own when I met our local developer relations lead.
That was three months ago. Today, I, weary and happy, can say that the first design sprint in Turkey and one of the largest design sprints to be ever held has just completed. These are my thoughts and notes on how it started, how I designed it, what worked, what didn’t, and how to do it better the next time.
The event had a special significance to us: it the first design sprint in Turkey and was likely the largest (if not the largest) to ever have run in Europe. A part of Google’s Launchpad program, we used Google’s offices in Istanbul.
What is a design sprint?
If you prefer to hear it from the horse’s mouth: gv.com/sprint
In short, design sprints are a condensation of the decision-making, engineering and design processes into a very narrow time frame in which the participating team generates ideas, creates structures in which to refer to their user base, validates their solutions, and builds a prototype.
It’s being used in Google Ventures, GV startups, and within Google, where it’s a very popular way to get teams to focus, run, and execute towards a common goal.
The Istanbul Sprints
This is a documentation of my experience designing and running the 3 sprints across 4 days in Istanbul, as well as some notes on how to do it better the next time. What might follow this post is a how-to on designing and running sprints.
Mind that what is provided here is only a common archetype and not a prescription; sprints can be designed and executed in quite a few other paths. The sprint I designed was tailored to the particular mix of participants we had, your needs might be different.
That said, I believe most of the process is fairly common across all sprints.
It should also be noted that while I work for Google, this is my personal recollection of the event as the instructor. I don’t speak for Google. In addition, we had to blur out the non-Googlers in the photos due to local regulation. Sorry about that. If you want to be unblurred, let me know (@nehbit).
More photos from the event. All photos are from the first day of the sprints.
The preparation and challenges
Design sprints are usually run for one team at the time, not for 20 of them, and certainly not with 110 people participating. That was the main challenge; the amount and breadth of startups participating in the event, in addition to the size, stage, funding and the industries they operate in. While you can also run a sprint with multiple teams, they work best when there’s only one team, one goal, and 7-10 people in the room.
We ended up deciding to split in such a way that roughly grouped them by their stage. This allowed us to pick groups of people that were thinking about the same structural issues of growth and user acquisition regardless of their industry or funding, creating a lively band of participants while retaining a focal point to which I could design that day’s sprint.
In the end, we’ve decided to run 3 sprints in total, while progressively moving the average to latter stage companies. The first two days became two one-day sprints, and we used the last two to build a two-day sprint to better accommodate for our most mature participating teams. It goes without saying that it didn’t work perfectly, in that some participating teams had time restrictions that forced to join only a certain day or the other. But in general, we had the chance to morph the sprint towards what the participants would be thinking that day at their offices, had they not come to our sprint. At all three of the sprints, we ended up with prototyping and presentations, though the roads to that point differed based on that day’s mix.
Designing and running the sprint
This is where we had a couple differences from a sprint that would run within a company: sprints usually have an overarching question that serves as a focal point on which the entire sprint runs. Not only I did not have that, I also didn’t have the luxury to move all of the teams towards the same goal; they were separate startups or companies with their own concerns. For half of the sprint’s aim, which was to teach them how to run their own sprints, it didn’t matter, but for the other half where I wanted them to have some decisions, it required a little bit of thinking.
Fortunately, we had anticipated this problem; we had asked the startups in the application form what they wanted to sprint on. That predictably ended up being a limited success. We received some good answers, most of the answers were too specific. (E.g. they wanted to convert their website to responsive design.) This wasn’t a fault, though; we hadn’t had a chance to explain what a sprint was at that point, and seeing that this was the first sprint to ever run in Istanbul, they had no experience of any past sprint.
To handle this, I decided to cheat a bit, and use the information we’ve had from splitting the startups into the three sprints. In the light of that, the meta-question of the first sprint ended up how to improve their core product, the second how to increase user acquisition, and the third, how to serve their current and desired user base.
After drafting a rough plan applicable to all three, I started to outline the individual sprints. For the first one-day one, we created ideas, debated them, we worked through the cost / benefit analysis, defined the expected return, created user journeys, storyboards, anonymously voted both internally within their team, and externally within the whole of participants, and finally built a prototype.
In the second one-day sprint, in addition to all of the above, I added personas and success metrics to solidify the cost / benefit analysis into a stronger bedrock upon which the participants could build their ideas.
The reason for adding things to the second sprint that weren’t available on the first one was that the startups on the first sprint were generally at an earlier stage. They did not have the analytics or user insight to create well-defined personas, nor they did have the analysts to create them. For the success metrics a similar reasoning existed: groups from the first sprint were still working on the core workings of their products, and hadn’t yet gotten to a stage at which the cost of an additional feature could be evaluated.
For the third and the last sprint, the two-day one, we had some later-stage products and companies on board such as the Turkish Digital Service (E-Government / E-Devlet) and Wondr amongst others. The design of this sprint focused on a more mature track in which we explicitly created additional features based on existing customer problems, evaluated their feasibility and cost/benefit ratio, set up explicit and quantified success metrics (such as 5% increase in user retention at 6-month mark of feature launch, 15% decrease in app abandonment over 6 months at 1-year mark of release, etc). After this, we’ve moved into structuring the proposed solution and the journey into a form that could be explained to an outsider. Finally, we did some preliminary anonymous internal and external voting to get the participants to have some gauge of popularity both within their team and outside of it.
The second day of the two-day sprint added two novel exercises. I talked briefly about user surveys to both test the viability of their own proposed solutions, and to confirm that the personas they think they have actually exists in the wild. The teams built their surveys under some guidance afterwards.
Consequently, I kicked out the participants out of the office for two hours, within which they were asked to collect three surveys per person from their personas, and talk to their users. Admittedly this was happening in Istanbul’s Levent district, which had a certain predilection for white-collar businesspeople, so this was easier for some groups such as the Turkish Digital Service, who could ask quite literally anybody with roughly 80 million users (they ended up asking bus drivers), and harder for others which were in specialised industries like 3d printing.
Following this, we had a quick presentation about what they’ve gotten out of it after all the teams were back in the office. We had a couple major changes to the proposed solutions that I was very happy to see were based on actual user feedback.
The next step was to build a prototype, which we had some more time to deal with than shorter one-day sprints. But at the end of the building phase, we did one more thing—after a quick introduction to user testing, we created the test script, we’ve picked one person to take notes from each team, one person to ask questions, and converted the rest of the team into user testers for other teams. At the end of this process, each team had their prototype of the proposed solution to be tested by roughly 5 people that was completely new to the work. Up until that point I had prevented prototypes to be seen by anybody other than people in the same team to keep it unbiased to maintain the integrity of the user test.
When we had the final presentations at the end of the day, it was great to see that both of the exercises that were new to the two day sprint were amongst the most successful: more than half of the teams had at least one major issue come up, which affected their work drastically. I was happy to see that all of the teams could quantify what they have gotten out of the user survey (idea validation, talking to customers) and the user tests (product validation), and were extremely eager to go home and immediately implement the changes.
Conclusion
My aim in designing all three sprints was that all of our participating teams would end up with an useful product, that at least one artefact from the sprint would still be useful long after the sprint ended. For the first sprint it was a prototype to be tested. For the second, we built personas, success metrics and a prototype based on them, all of which, I hope, would be used afterwards.
For the final two-day sprint, we ended up with personas, success metrics, user surveys and results for idea validation, a prototype, and a completed user test and its final report.
Beyond these, what I had hoped to impart in all three sprints was the conviction and the tools to run their own sprints internally. I don’t have metrics on how successful this last one went down yet, but considering the anecdotes that I heard, I’m optimistic.
What went well
Above most success metrics, I was happy to see that all of the teams participating in the sprint managed to build and present a prototype, which was no small challenge given the time constraints. They definitely had their work cut out for them. With the exception of one team which could not finish the prototype on time for user testing, all the teams managed to deliver on time.
Half of the idea behind the sprint was to actually teach people to do sprints. I have received quite a few questions about how to design them and how to adapt them to their own needs, to which this post and the upcoming one is an attempt to answer.
The quality of the startups, their professionalism and the rigour they applied themselves to the process was beyond my expectations, and above what I would normally expect from Turkey in which none of the teams had prior experience of an actual sprint. I’m fairly impressed, I expect quite a few success stories from the teams participating in the future.
In retrospect & what could be better
These are my takeaways from the experience to make it better the next time around.
1) If I had a chance to repeat it, I would run the same sprint in Day 1 and Day 2. The time constraint was not as strenuous as I thought, and having different sprints created an overhead that nullified the time advantage anyway. The startups from the first sprint could definitely benefit from having success metrics and personas on the line.
Takeaway: Minimise the amount of sprint configurations you are running—it’s usually best to stick to one.
2) In the latter two day sprint, I would slightly move the order of the sprint processes a bit to allow for a smoother flow from ideation to execution. To keep it as simple as possible to process, I designed the sprint in such a way that the majority of ideation process happened in the first day, and the second day the participants validated, prototyped and tested their ideas. This created an easier progression to follow, but it did have the headroom to make it a bit more complex and organic.
Takeaway: The process should flow smoothly from idea creation, to validation, to execution. Avoid jarring switches that can make people feel lost. Don’t underestimate your participants.
4) And finally, based on the experience of the two-day sprint, I would add some idea and product validation phases to even the one-day sprint, considering how successful they ended up being.
Takeaway: However little the time you have, try to follow through with the full process.
Our teams
We had 20 teams spread across three days, some of them fairly early stage, and some of them with quite a bit of revenue. While I wouldn’t be able to cover all the teams that participated, here’s a semi-random assortment of them, in hopes that this’ll help them get a bit more of the spotlight they deserve.
Webnak
Webnak is a platform that connects lorry drivers to businesses who need commercial goods shipped. For drivers, it increases the shipment availability and protects them against damages with automatic insurance. For businesses, it provides them the best market price based on bids on their cargo, allows for modern modes of payment, and tracks the cargo via GPS to the destination.
Fitwell
Fitwell is a fitness app that provides full package personal coaching service, with the ability to replace a personal trainer, a nutritionist, and a life coach. It provides for fitness tracking, personalised exercises for different sports such as snowboarding, or for a specified end result, such as looking good on the beach.
Tazedirekt
Tazedirekt is a provider of high-quality, organic food products backed by a network of farms that produce the inventory sold through the website. Amongst other things they provide high-quality meat, fruits, vegetables, cheese and dairy products grown and produced locally, and they themselves handle farm-to-table delivery without breaking the cold chain.
BiTaksi
BiTaksi provides a convenient method to call local taxis in Istanbul. They provide a credit-card based payment system, a reputation structure and a loyalty program for taxis, none of which are available otherwise.
Connected2.me / Wondr
Connected2.me (Wondr) provides anonymous chats with your Twitter followers. This is useful in circumstances where celebrities want to host chatrooms for their followers, or where groups of friends create persistent chatrooms in which everyone is anonymous.
Dugun.com
Dugun.com provides a platform for everything needed for a successful wedding. It strives to be a platform which brings together locations, wedding gowns, photographer contractors, graphic design services for invitations, food service, rental cars and honeymoon packages. Fairly thorough.
Turkish Digital Service (E-government / Turksat)
Turkish Digital Service provides Turkiye.gov.tr, which is the online centralised platform upon which more than 1200 government services related to pretty much anything, including taxation, higher education, social security administration, healthcare, retirement, and matters of the judiciary. With all citizens of Turkey being a 'customer’, the Service provides one single product all citizens of Turkey needs, one way or the other.
N11
N11 is a general-purpose e-commerce store that allows for third-party storefronts, much like eBay and Amazon Marketplace.
Şirketçe
Sirketce provides a business-to-business search engine for Turkish companies, in which they can advertise their goods, services, and provide contact information.
Hürriyet
Hurriyet is one of the major newspapers in Turkey. According to comScore, its website is the third most visited news website in Europe, after Daily Mail and The Guardian. The representing team at the sprint was their mobile department.
Andrig
Andrig is a mobile application that turns your Android device into an electric and bass guitar amplifier kit. Instead of investing in expensive and hard-to-carry amp, electric guitar players can quickly access, affordably purchase, and enjoy using Andrig easily on their mobile devices anywhere with their electric guitars.
Weact
Weact is a yet-to-be-released social application that lets you build arrangement 'movies’ with clips collected from your friends that is passed back and forth.
Credits: the sprint team
Above and beyond anything, the first thing I would say about all this would be that it would be impossible without the team we had: Karina Ibarra(@karinai) and Andres Martinez (@davilagrau) both graciously accepting a detour all the way from Spain to help as facilitators. Rıza Selçuk Saydam (@rssems), the soon-to-be Facebook designer and Murat Yener (@yenerm), our resident Android expert from Intel, were acting as our local support. Barış Yesugey (@barishko) was at planning, coordination and logistics, and I (@nehbit) was the sprint master, designing and running the sprints. I cannot credit them enough.