Last weekend I attended the Start-up Experience hosted at Northumbria University Student & Graduate Enterprise, in association with the Startup Foundation and Santander Universities. The event ran from Friday evening until Sunday afternoon and was a cohesive mixture of informal talks and group tasks which would help us redefine our understanding of what startup means and gave us an overview of the agile approach to product/solution development.
#marshmallow challenge at #NUStartupWE @startupfndtn @NUOVOsociety @FIRST_ftf love it! pic.twitter.com/rUO7Q6bqcO
— Northumbria Uni Student and Graduate Enterprise (@NUEnterprise) March 11, 2016
During the first evening, we learnt that a start-up is not, and should not be thought of as, a company. Instead, we were told to think of them as temporary organisations that are seeking a repeatable and scalable business model, while companies should be seen as entities which are currently executing a proven model. Various historical examples (read: failures) were shown and a convincing argument for adopting lean and agile development practices was given. The slides above briefly highlight the key points covered on Friday evening, including the importance of customer discovery and validation, which was reinforced throughout the whole weekend. Most of the presentations used for the event have also been added to SlideShare by Leon Pal, Chairman of the Startup Foundation and main speaker at the event.
I found these insights very useful, as I have been learning about and practising lean and agile software development methodologies through university. So it was encouraging to see that those philosophies are somewhat transferable to my goal of running a startup through the Northumbria Hatchery.
For the rest of the evening we assembled groups based on problem themes – topics such as finance, work, travel, retail or any other area we felt passionate about improving – and then set about applying some of the taught strategies ourselves, focussing firstly on the value proposition and customer segments of a business model design canvas. We also tried our hand at – and gloriously failed – the Marshmallow Challenge, which really reinforced the importance of iterative prototyping in order to find a successful solution sooner. An interesting explanation of the challenge and its pearls of wisdom I have included below.
ARVE Error: src mismatch
src in org: https://embed.ted.com/talks/tom_wujec_build_a_tower_build_a_team
src gen org: https://embed.ted.com/talks/837
Saturday started with walkthroughs of lean startup processes which involved ‘Learn and Confirm‘ and ‘Customer Conversation‘ segments, which taught us the value of getting out of the building and starting customer conversations around the problems we identified in our teams the night before. We refer to these as our problem statements. The idea being that actual primary field research would either validate or invalidate our problem statements and help us decide if we should pivot (a fundamental change in the business model) or proceed with developing a solution. By doing so we avoid developing a product/service based on our assumptions, that has no real customers willing to pay for our product/solution.
Thankfully our team worked well together and we tackled this task well enough to both validate and invalidate different assumptions that had led us to our problem statement. By going back and reviewing what we had learnt we decided to pivot our idea in terms of the customer segment and their needs. This helped grow us from the idea of hiring out food trucks to local businesses to instead aiming to provide a venue for local chefs and ‘foodies’ to try out their own startup at a pop-up stall in key city locations.
The key here is that we again needed to test our assumptions to gather real-world data on our renewed problem statement. So we quickly developed a social media presence and spread the word among our target audience in order to get validation, in the form of customer participation tests. This took the form of a simple competition in which we encouraged people to submit images of their best culinary creations using the hashtag #icookedit2016. We set a fail condition, a minimum of 100 responses, from which we could find perhaps 10-12 people who would come to cook and sell their dishes at our venue in Newcastle.
After promoting the competition overnight we returned on Sunday to the event and started analysing our results in order to help us give a five-minute presentation “pitch”, which consisted of an explanation of our journey and key findings we took from the weekend’s activities. The deconstruction was just as helpful as the activities that preceded it and even helped us understand and identify how we could take the idea further if we had more time to develop our problem statement and solution.
The slides we produced are included above but don’t really explain the concept or the joy of challenge, learning and discovery we all had in developing our startup over the three days. Even though we did not get the results we wanted we had applied everything we were taught and each team member agreed that we could see the benefits of the lean and agile startup approach.
Team I Cooked It's market research sounds amazing – eating their way across Newcastle #NUStartupWE #ICookedit2016 pic.twitter.com/7BAxUwfQpf
— Northumbria Uni Student and Graduate Enterprise (@NUEnterprise) March 13, 2016
In closing I got a great deal from the event and would highly recommend this or similar events to anyone looking to go into, or even considering from a curious distance, running their own startup. At least reading up on and trying out different methodologies will help you avoid the pitfalls of that blinkered approach we too often default to in life and help you stay focused on developing a minimum viable product (MVP) which is backed by a viable business model and has proven worth to customers that are actually willing to engage with it.
Thanks to all those involved! Invaluable.
Lesson learnt: Don’t build so fast that you didn’t have time to test your assumptions because your assumptions are mostly wrong. Aim for a solid, stable base (MVP) and iterate rapidly through your testing phase to find out what exactly that base consists of. You have to be able to build a skateboard before you can start to get anywhere near building a car. Learn, validate, re-learn, re-validate…repeat until $$$.