17 Jul 2019
What makes a good opening trick at a close-up gig?
Your opener has to be something which establishes that:
- You are a professional who has been hired by the venue or event planner, and you’re not just an eager stranger chance-ing for tips.
- You are a magician.
- You are a good magician.
- You are friendly and not trying to con anyone.
- You’re going to entertain them / they’ll be glad to have given you their attention.
This is a lot to convey in a few minutes of magic.
Luckily, you can get through a lot of it with your introduction / approach. Let’s assume you’re doing card tricks at a drinks event, maybe a champagne reception before a business dinner. By approaching a group and saying something like
Hi there! Sorry to interrupt — I’m the magician for the evening. Would you like to see a quick magic trick?
you can cover points 1 and 2. And, if you’ve got a friendly and confident manner, you can probably make a good start on 4 and 5.
But what about point 3? How do you quickly convince them you’re a good magician, while coming across friendly, entertaining, not-arrogant, and with a normal deck of cards?
That’s what this trick is for.
Not That One
Effect: The spectator chooses a card. It’s seemingly a free choice every time, but as the magicians tells them not to pick that one… the card says ‘Not That One.’ They try again, but pick the same card. This process repeats; each time, despite seeming like a free choice, the spectator chooses the Not That One card. Exasperated, the magician shows that every other card is made up of blank cards. But, with a snap of the magician’s fingers, the ink reappears on every card.
Method (in brief):
You repeatedly force a card, and then do a reverse spread with the Ace of Diamonds at the face to show a ‘blank deck.’ Nothing revolutionary! But, given the above, I think this makes for a great opener.
Method (in more detail):
I’ve written this out in a lot of detail, but please remember, this is a super, super quick trick, and just introduces you before you do a lot more magic.
Setup the deck by finding the two red aces. On one of them, write ‘NOT THAT ONE’ using a red Sharpie. (Pro tip: At gigs, I always use a red Sharpie inside a Sherpa case. It’s just a personal preference, but I think it brings a bit more colour to a performance than just having black Sharpies.) I use the central heart on the Ace of Hearts to form the ‘A’ in ‘THAT.’ Place the Not That One card on the top of the deck, and the other Ace below it.
Approach the spectator with a smile and with the deck held out. Say your opening line — as you say it, you’re already gesturing towards them to pick a card out.
(Approaching them with the deck held out helps with point 2, conveying that you’re a magician, and having your hands out and an open body language helps to subconsciously get the spectators on your side. And, if one of them has been at an event with a magician, they’ll (hopefully) be excited and eager to see what you can do. There’s a lot more I could say about approaching groups, and how to build confidence if you’re new to it, but I learnt it all from Jamie D. Grant’s wonderful book, The Approach.)
Classic force the force card while saying ‘Take out any one of these cards…’. After they’ve taken it out, and as they’re turning over, let your face drop, and in a serious voice, continue: ‘…but not that one.’ They’ll look at you, confused, then look back at the now face-up card, realise what’s happened, and laugh. I’m labouring this in-detail but this should all be in one fluid sentence and gesture, and happen in a mere matter of seconds.
If you’re worrying about the classic force, don’t. The main reason that classic forcing doesn’t work is that a spectator has a reason to doubt you or a desire to challenge you. If you follow the above advice and opening line, they should be intrigued, curious, and on your side — and they’ll take the card you give them.
Continue the trick by shuffling the Not That One card back into the deck, and forcing it in a different way to someone else. Again, say they can choose any card… but (as they turn it over) not that one.
Continue this for as long as you have different forces, until, feigning exasperation, you exclaim “I can’t believe you keep choosing the wrong card, especially as all the rest are blank.” At this point, they’ll have the Not That One card, and you’ll do a reverse spread. Have the Ace of Diamonds on the face of the pack (either keep it controlled throughout, or cull it to the face). Your thumb covers the pips and the center diamond, meaning the pack will look completely blank. You only show this for a second, before closing it back up.
Whenever you want, you can have a spectator click their fingers, and all the cards magically ‘come back’. You’re then ready for your next trick.
Pros and Cons
I really like this trick as an opener for a number of reasons. As I said above, I like approaching holding a pack of cards. I don’t like overly-flashy openers, with flash paper or elaborate card flourishes — they’re not my style. I find that approaching in an understated way is charming and disarming and sets me up for some really impressive miracles later on.
This trick also builds up in a nice way. It follows an absurdity curve: it starts off a bit odd and quickly gets bizarre. (If you haven’t heard of this, it’s something improv comedians use when creating sketches on the spot.) All the subsequent tricks should also be on this same curve, that builds slowly and then very quickly. As this trick is by no means the most miraculous trick, it means I still have lots of room to build up from it.
Lastly, it’s practical. Other great openers I like are Truth in Advertising by John Guasteferro, and the famed Chicago Opener. But they both need a gimmick (albeit only one card). This trick, however, is easy to set up from a new deck, as you just need a Sharpie, and easy to set up after leaving one group, as you just need to find one or two cards. You can just keep the Not That One card in the deck, and if it comes up in another trick you can make a joke about it.
The main drawback of this trick is that it sort of ‘gives away’ what forcing cards is by making a joke about it. You never repeat the same method of forcing, but arguably by just repeating any force, your spectator will learn that you can control and force cards. But I’m okay with this drawback — none of the rest of my tricks rely heavily on forcing, and moreover, because you’re make a joke about it, your spectators are unlikely to really hone in on it.
Have fun with this!
12 Jun 2019
Quick update — an essay I wrote, looking at links between art, magic and philosophy, was recently published as part of Volume 1 of The Neat Review.
The Neat Review is a magazine/journal that looks at the interdisciplinary links between magic and other domains, and the first volume has some great essays, some great card tricks, and an interview with Derren Brown. Each copy is £30 and you can buy a copy online here, or in various bookshops and magazine shops around London.
My essay can be read online here. If you do read it and have any feedback or ideas, please do send them to me. I’d love to hear them.
07 May 2019
This post was originally published on Medium.
In this article I cover (i) what the role of a facilitator is, (ii) how to prepare for a session where you are facilitating, (iii) what to do during the session and (iv) what to do after the session.
Read on to find out why you need the scoop on a group, what a POWER start is, and why having a plant in the room can really help you out.
A facilitator is a person whose role is to help a group of people reach a pre-specified outcome.
Facilitators don’t run a session. Training courses, company status updates, and other meetings which have a one-directional flow of information don’t need facilitators.
Instead, they facilitate, helping the meeting progress towards a specific outcome.
This can be a challenge for some people as it involves relinquishing control. The facilitator is not in control; the team are in control. The agenda, the process and the outcome are all ‘owned’ by the team, not by the facilitator. The facilitator needs to be okay with not contributing content, but instead being there to guide the team to the pre-defined outcome.
Often this outcome is about finding a solution to a specific problem. E.g., at the end of this meeting, we need to have found out how to grow by 10% over the next quarter. But, it can also be a more concrete deliverable. E.g., at the end of this meeting, we need to have a design system for our new branding. The outcome or deliverable of the session should be defined upfront.
Prepare for a session by: interviewing the key sponsor, researching the context, planning the session and communicating with participants.
There are four things you need to do when preparing to facilitate a session.
Firstly, you need to identify and interview the key sponsor. This may be a CEO, a project lead, or similar. Ask them what the purpose of the session is, if they have suggestions for how the session should be approached, and what they expect the outcome to be.
You need to find out what role they are playing in the session. A manager sitting in on a meeting can fundamentally change the dynamic of the meeting, so might not be appropriate, depending on what your outcome needs to be.
You can also take this opportunity to ask them for the scoop on the group. Are any of the personalities difficult to manage? Too loud, too shy, too controlling? Knowing this in advance will help you prepare.
Secondly, you need to figure out the context of the session. What do you need to know about the company culture? What do you need to know about the health of the business? What about the environment? And any current events that might be relevant?
Thirdly, you need to actually design the session. Work out the agenda if you’re in charge of deciding it. Identify any tools or supplies you’ll need. Estimate the timing of each item on the agenda. If possible, visit the room beforehand, to check all the tech works. Drawing out the layout of the room can also help to visualise the space you’ll have available. Make sure the room you choose meets the accessibility requirements of the participants who’ll be attending.
Lastly, communicate with the participants beforehand. Send out the agenda, but be wary of sending out a strict time schedule, as having some flexibility can be beneficial if you need to change things around. Send out logistics regarding location and timing, and any accessibility information about the room you are in.
During the session: kick off with a POWER start, keep the group engaged, and if necessary, record what happens.
The session should be an open and comfortable environment. One way to get everyone in the right mindset is to use a POWER start.
A POWER start involves:
- PO: Outline the purpose and objectives of the session
- W: Make sure everyone knows what’s in it for me
- E: Build the energy in the room so everyone’s feel upbeat, and motivated (music and icebreakers help with this)
- R: Set the rules (e.g., don’t continiously text on your pocket phone, don’t talk over others, figure out who has final say on decision-making)
If you’ve got a tough crowd, you can pick a plant to be on your side. Approach someone before the session starts, and ask them to be super enthusiastic and upbeat. They’ll be the first to ask questions, offer suggestions, join in with the icebreaker.
Not this kind of plant! Although plants are sick and good for air quality so you should also have some in the room if possible!
Make sure to project when speaking and to start on time. If there are latecomers, check with the rest of the group whether they want to wait for them or start without them.
To keep the group engaged you can use a variety of interactive activities. Having ice-breakers, getting everyone out of their seats to throw out ideas on post-its, or voting with a service like Kahoot will keep people interested and help the group reach their outcome.
Make sure to record the decisions and output of the session if required. (This is something to check with the sponsor!) If you aren’t able to record while also facilitating, you can delegate and designate one person as recorder.
After the session, communicate with the group.
Sometime after the session, you should send an email to the group with a reminder of what was accomplished. For example, if flipcharts were used to record the outcome, you can send out photographs of them. You can also use this opportunity to send out self-reflection questions to the participants or a feedback questionnaire.
You should have a debrief with the key sponsor about what was accomplished and if the outcome was reached.
Lastly, and most importantly, you should transfer accountability. Now that the session is over, who is going to continue with the project and facilitate future sessions? Make sure all of the pariticpants know who that person is.
19 Apr 2019
This post was originally published on Medium.
In this article I briefly describe my process of redesigning the NHS Blood Donation app based on a set of usability tests.
This was a short project to practice the process of auditing the user experience of an existing app. I therefore didn’t end up redesigning the whole app, but just made a start on it to see the new direction it would go in.
I cover why I chose this app, the research and design processes, and the lessons I learnt. Thanks for reading!
- A note on unsolicited redesigns; why I chose this app
- Usability tests
- Collecting results of usability tests
- Other ‘UX Deliverables’
- UX conclusions ➜ UI decisions
- New protoype and more usability tests
- Future additions & lessons learnt
1. A note on unsolicited redesigns, and why I chose to redesign this app
Generally, I’m not a fan of unsolicited redesigns. They are often done mindlessly, without considering the purpose of the redesign. (This article covers some of the problems with unsolicited redesigns.)
But in this case, I am, on purpose, choosing not to look at the visual design elements of this app. I think the user experience parts of the app are much more interesting to examine. The conclusions that result from this UX research can then guide the redesign.
Moreover, I think that (in this specific app that I’ve chosen) the individual design elements are good. The app is part of the NHS, which has some great design and branding guidelines, and the blood donation service itself has a really good logo. What does need work is the usability of the app.
So let’s test the usability and see what we can fix!
2. Usability tests
There are lots of ways of researching how users use a product. Usability tests fit into the following category:
Instead of focus groups or surveys, which look at what a user reports about their use of a product, a usability test observes the user’s behaviour.
It doesn’t always make sense to do a usability test (e.g. if you are creating a new product from scratch.) But if you’re working on improving an existing product, then arguably it’s the most important of user testing that you can do.
How to do a usability test
I booked out a small room, set up a video camera on a tripod, and invited in participants to do a test one by one. (In my case, these were some friends that I’d roped in — thanks gang!) They were each given a phone with the app already installed and logged in, and were asked to complete four tasks as part of the test.
‘Test’ is a misnomer. There’s nothing that your participants can do that is the ‘right’ or ‘wrong’ thing. You just want to watch what they would naturally do.
You’ll want to standardise your script, so everyone is given the same introduction, background and the same tasks to complete.
Unmoderated tests will probably max out at about 15 minutes, whereas moderated tests (like the ones I did) could last for up to an hour.
To decide what tasks you give your participants, you need to work out: what problems people are using your product to solve, who your users are, who your competitors are and what they’re doing differently, what the unique value proposition of your product is, and so on. Take a look at the Lean Canvas if you’ve never seen it. It’s a great, quick way to answer all of these questions.
(In my case, I only had a four tasks, and none of them covered the new user or login flow. This was because I wanted to keep the scope of this project quite small. In a real project, you would provide enough tasks to cover the entire user flow through the app, including signing up. You’d probably also pay your testers for their time, either in vouchers or cold hard cash. Sorry gang!)
The tasks I gave my testers to complete were:
- Book an appointment to give blood at a time and place convenient to you.
- Find out what blood type you are.
- Determine if you are eligible to give blood, given that you had a tattoo 8weeks ago.
- Determine if you are eligible to give blood, given that you got back from Kuala Lumpur in Malaysia last month.
When your participants perform the tasks, it’s important not to interrupt or break their process. It can be frustrating watching someone repeatedly tap the same button when there’s an ‘obvious’ right way to do something, but that’s the whole point. The participant isn’t doing it wrongly — instead, your product is not designed optimally.
You want the participant to narrate what they’re doing and what they’re thinking. But don’t use leading questions or say anything that could give them a hint about what to do. Instead, use open questions (e.g. “tell me about what you’re seeing”) so that you get an unbiased view.
To decide how many people to run usability tests with, first consider how many user types you can have. Often this segmentation of user types is encapsulated in fictional personas, e.g. Good Guy Greg or Cash-Strapped Casey. (If you have Skillshare, this short course about personas is a great run-down.) As a general rule, you want to try and run 3–5 usability tests for each persona type, and around 10 in total. But running usability tests and analysing the results takes a lot of time, so this will definitely vary depending on budget.
3. Collecting results of usability tests
Now that you’ve set up your usability tests — what are you actually looking out for? We can break this up into quantitative results and qualitative results.
For each task, you should quantify the participant’s success.
One way is to rank success in three levels: (1) the participant was unsuccessful, (2) the participant was successful but with lots of help from you, and (3) the participant was successful by themselves. For the tasks that are unsuccessful or where the participant needed help, you should note down why that was.
Another way is to measure the time taken to complete each task.
After each task you should ask the participant questions: did anything about that strike you as particularly good or bad? Did you feel something could have been explained better?
You can also collect initial impressions of the product: what do you think the purpose of this app is? Where would you click first if you saw this screen?
And ask ‘exit interview’ questions: what three words would you use to describe this product? what did you like least about the product? would you pay £X to use this product?
As well as an exit-interview, you can send out a post-test survey, to collect their thoughts after some time has passed. This allows you to see if their impression of the product has changed, and what stood out so much that they remembered it.
These are qualitative questions, but because they’re standardised across every participant, they can be used to spot trends. The results could also be made quantitative by applying a scoring system to the answers you receive.
When doing the test, you should look out for participants who say things like “that was weird” or “Oh, I didn’t spot that, but that was my fault, I was being really dumb.” This is a telling clue: the participant isn’t being dumb — it’s your product that needs work.
It’s important to remember that you want to list down positive things with the app, and things your participants liked, as well as negative things.
4. Other ‘UX Deliverables’
I don’t think there should ever be a concrete list of ‘UX deliverables’ that have to be delivered for a project. What ends up being a part of your UX audit or report will always depend on the specific product, client, customer segments, etc.
Here are some other things that I did for this project, as well as usability tests.
- Customer Journey Map / Experience Map that outlines a customer’s experience or journey as they go through the app
- A Funnel Matrix outlines where users are along the funnel and how to ‘acquire’ them as users of the product, and metrics for success (watch this talk for more info)
- Personas to encapsulate who your user types are, based on the research you’ve done
- A heuristic evaluation of the app (I recommend choosing a subset of Jakob’s heuristics and seeing if every aspect of the product adheres to them)
5. UX conclusions ➜ UI decisions
Let me start this section by saying that the current app works fine. It’s not unusable. You can use it just fine to make appointments. I’ve personally used it successfully for years. And I imagine that thousands and thousands of people use it every month to book appointments. It does what it needs to.
But it could be better.
Some suggestions specific to thisI gained from my usability testing and heuristic analysis were that:
- Only days/locations with free appointments should be shown on the search results page
This actually matches up to lots of the recent reviews on the Play store:
- Filtering results needed to be easier / it was hard to spot how to apply filters
- Health and travel information was duplicated in different places in the app
- The menus were confusing to navigate
- The back button didn’t work properly when booking an appointment (i.e. the state wasn’t being saved when searching and booking an appointment)
- Some copy can be made clearer e.g. hard to know what “donation credits” meant
- There was an overwhelming amount of info on the health results page (half of my participants failed the task to determine if they were eligible to donate having visited Malaysia, solely because they skim-read the block of text on Malaysia)
One of the main takeaways from these results is about navigation. It’s hard to get around the app as it currently is, because there are hidden menus, there are multiple ways to navigate to the same place, and the back button is unpredictable. Moreover, there’s no clear reminder of where you are in the app.
So one of the main things I add in my new prototype is a persistent bottom navigation.
6. New protoype and more usability tests
The navigation in this prototype is always on screen, and you can jump to every section from wherever you are.
Instead of the current app’s slide-in-from-top hamburger menu with 8 items, I chose to only have four sections.
All health and travel info is covered in the eligibility section, and nowhere else. Booking appointments and seeing previous appointments is all done in the appointments section. Viewing and changing profile is done in the profile section.
Each new redesign should go through the same usability tests. My re-tests were limited as I only designed the screens you can see here, but the participants did complete the same tasks faster and more successfully using the new design.
7. Future steps & lessons learnt
Future work could be about combining the location and datepicker. Having to go back and forth between a location and a a suitable day and time is frustrating.
In the above gif, you can see that I started the appointment booking flow by asking users to choose how they want to book an appointment, either by date and time or by a convenient location. But I think that even this simple choice gives the user too much responsibility. I’m sure there’s a way to combine these options into a single slick booking flow.
A good thing about the current app which I didn’t mention above is it’s similarity to the web version. (I think the booking part of the current app may just be a scaled down and embedded web view displaying that portion of the website.) This is good. There should be a consistency between them, as after all, they are doing the same thing, regardless if its a website or an app. A full redesign should account for this, and make sure to update both the website and the app together.
One way would be to make a single responsive design that works at any screen size and scales appropriately. (Some high-fidelity prototyping tools, like Framer, XD and InVision, are moving towards including this).
I learnt a huge amount while doing this project. Lots was in terms of the UX process, as I describe above, but I also learnt lots of UI best practices when designing the prototype in Figma. (I didn’t touch on that in this article, but a lot came from Refactoring UI, which you should definitely check out if you’re interested in UI design.)
Thanks for reading!
(PS: If you don’t give blood and are able to, it’s (a) really quick, (b) it’s a good thing to do, and, (c) weirdly, it’s kind of fun. Check out blood.co.uk if you are in England, and the equivalent service if you’re in different parts of the UK or other countries!)
27 Mar 2019
Last weekend I attended Startup Weekend Oxford: Fintech Edition. It was the third startup weekend I’ve attended, having been to one in Oxford two years ago and one in London late last year. I love them — each time I’ve been, I’ve met really lovely people, and had fun working on really cool ideas. This time the team that I was a part of won first prize!
Our team, the judges and the organisers
What is a Startup Weekend?
Startup Weekends are organised by Techstars in partnership with Google for Entrepreneurs. Over a weekend, 50-80 people self-organise into small teams, come up with a startup idea, validate the idea, and pitch it.
Despite the weekend being full-on, it has a defined structure. (In comparison, hackathons, in my experience, are twenty-four hours of solid coding).
On Friday, everyone arrives, mingles, has some food and drink, and is invited to pitch an idea for a startup that they haven’t yet worked on. People vote on the ideas, and the top 7 (or so) are chosen. Everyone forms into teams: one team per idea. with people they’ve never met before. On Friday night, throughout Saturday, and on Sunday morning, the team works on the idea: coming up with a prototype, a business plan, a growth strategy, and putting it all into a pitch deck.
On Saturday there are workshops. There are about how to validate a problem, pitching, growth strategies and so on. There are also mentors from related industries, who have lots of experience and so can answer questions and offer advice.
On Sunday, all the teams pitch (for just 5 minutes!) to a panel of judges. Each team is judged on three criteria: (i) the validation of the problem and the innovation of the solution, (ii) the execution of the solution, and (iii) the business model. Then the winners are announced. And then, beer.
Getting a team together
I didn’t pitch an idea at the previous two startup weekends I went to. I actually ended up being on teams working on social enterprises at both. The first one was a ‘pledge-swapping’ app, where users could meet other socially-minded users and commit to (for example) going vegetarian for a week in excahnge for signing up to the Labour party membership. The second idea was about encouraging people to boycott brands that had bad human rights practices and offer ethical alternatives.
Photo of me answering a question from the judges at Startup Weekend Oxford 2017.
So this time around I was keen to pitch an idea, but didn’t have anything fleshed out. But I did, however, have a (macro) problem that I thought needed solving. Renting is crazy expensive (especially when living in London in your early 20s) and saving enough to get onto the property ladder while paying so much in rent is nearly impossible.
Unlike most pitches, I didn’t pitch a solution. I had no sexy app in mind to solve this problem. I did, however, have a concept in mind that could be used: property guardianship.
In brief, a property guardian is someone who enters into an agreement with a company to live in an otherwise unoccupied building. Property guardian is not an officially recognised term; it is used to denote a resident who doesn’t have a lease agreement so is technically not a ‘tenant’. The company who owns the building saves huge amounts in insurance and empty building tax (in some cases a £110k p.a. bill dropped to £15k p.a.) and the guardian gets to live cheaply in a non-residential building. The buildings could be anything, from office blocks to disused hospitals. Often they have no furniture, and only have running water and a smoke alarm.
People pitching usually say who they want to join their team: designers, developers, marketers, and so on. I just asked for anyone who was keen to research the problem as much as possible, and see if we could find a solution. My pitch got enough votes and eventually we formed a team of 7.
The inital idea
Friday evening was spent doing a brain dump of all potential ideas. Saturday was spent doing a lot of research. There were lots of problems; one we kept coming back to was that potential property guardians don’t know what their legal rights as a guardian would be. We thought of pitching an app that compared different property guardian companies; an app that made it really easy to sign up and apply, and get NFC powered key access to a building; an app that targeted international students looking to live cheaply…
But all our research showed that none of these had a business case.
There are 40 or so companies that offer property guardianships, and only 7000 guardians in the UK. One company had a waiting list of 2000 people. The market was both small and crowded. Moreover, the appeal had disappeared: when these properties first appeared in the early 2000s, places could be ‘rented’ for a third of what normal rent was. Now the cost is basically the same, but you don’t get the same guarantees or provisions that a retner would. There are horror stories of deposits never being returned, guardians having to vacate within 24 hours, and more.
The nail in the coffin came when one of our team tracked down a journalist who had lived as a property guardian in multiple properties in the last ten years, and had written a piece about it in The Times. He told us that we really had no business case. Because of the rising cost to be a property guardian, our startup would make so little money running a service on top. And in his opinion, the whole scheme would “eat it’s own tail” and disappear in a matter of years.
We didn’t really have anywhere to go with the idea. It sounded great: 24,000 commerical properties in London alone are empty, and 11,000 of those have been empty for 2+ years (source). But we had nothing unique, and no way to convince those property owners that a person needing somewhere to cheap to live was better than a good security system until they could be sold.
So, on Saturday evening, three quarters of the way into the competition, we decided to scrap everything we’d done and start afresh.
## Episode IV — A New Hope
We ‘pivoted’. We came up with and refined a new idea: simplifying co-buying a house.
Groups of friends in their early 20s who are already renting together can save money by jointly buying a property and paying a mortgage together, and then, in four or five years time, they can sell it and buy somewhere else by themselves or with their significant other.
This is already possible to do, but people don’t do it, because it’s not easy. There are lots of difficult ‘what if’ questions. What if someone wants to get married and leaves? What if someone goes bankrupt and I’m held liable? What if two people want to buy out another person’s share?
Our app would show people explicitly what happens in these various scenarios, removing any worries, and would also show the savings made by not paying rent and by potential increase (or decrease) of the property’s value. The company would initially be profitable by gaining referral fees from conveyancers and mortgage brokers, and could eventually branch out into subsidiary revenue streams.
Although this idea focussed on a completely different problem, it solves the same macro problem: rent is expensive; how do I pay less rent?
Our team scrambled together a pitch deck, some figures to size the market and present a business case to show it was viable, we put together a quick prototype with Figma (I <3 Figma), and we pitched it. And we won!
The weekend was a blast. I already knew from previous startup weekends that the best startups have to actually solve a problem, instead of just creating a solution for a problem that no one has. But I never expected to pivot away from an idea so late into the competition, but still be able to end up winning.
Other lessons: a good pitch and a good prototype really make all the difference. Each team only had five minutes to communicate what we’d spent the whole weekend working on, so at the end of it all, it really came down to selling what we’d done to the judges, and getting them to believe in our idea.
I feel super lucky to have worked alongside such an amazing team throughout. We all listened to each other, worked collaboratively, and bounced ideas off each other. It was this that eventually allowing us to land on something really great.
Stay tuned for more info about our startup-in-progress!
PS: Matt also did a write-up about our team at Startup Weekend; you can read it here.