The concept of these Startup Weekend events is simple. You and a team of six to eight other event participants have 54 hours to turn a startup idea — usually something involving technology — into a minimal viable product (MVP), complete with market data and a go-to-market strategy. At the end of the 54 hours, you present to a panel of judges and your fellow competitors. The top three teams win prizes and a heightened sense of validation about their idea.
I paid the $100 without a particular technological solution in mind. I was more interested in joining a team for the purpose of professional development, networking, and — oddly enough — entertainment.
Most of all, I wanted to learn from this experience. I can say with confidence that I did just that. Below are a few useful insights I collected from these 54 hours.
Not everyone is equipped to talk to customers
It sounds intuitive that one should talk to prospective customers and intimately understand what their problems are before building anything so as to save time and money — often limited resources for entrepreneurs. It turns out that not everyone has the skill, intuition, or even willingness to have these kinds of conversations.
Observing the room, there were technical and non-technical people alike who were either keen on philosophizing about which target markets would be best to approach, or, if the team was stacked with engineers, focusing on the building a solution to a preconceived problem sans actual data.
The act of approaching someone else in the room, asking for a minute of their time, and having a thoughtful conversation about their problems appeared at first to be few and far between. Gradually, momentum for conducting customer interviews picked up, but that was only after the midway point of the event, and it seemed as though many were conducting interviews solely to justify and validate what they had already created. One engineer I spoke to said that he had never conducted a customer interview prior to this event — He openly admitted that interviewing customers was harder than he had expected and that he had initially found himself biasing some of his questions.
Voice-of-the-customer research is indeed both an art and a skill. However, throughout this Startup Weekend I got the impression that VOC research was undervalued, and that teams were more focused on having engineers build something cool and innovative, something that would captivate the audience and wow potential investors.
Engineers aren’t the only culprits forgetting the importance of VOC research. Among the non-technical folks at the event, and especially those who claimed to be in marketing or business development, there were some who honestly believed that they knew how to talk to customers, but for whatever reason just couldn’t do it when called upon by the team. I noticed more time being spent on creating prioritized lists of potential target markets, brainstorming how to pivot the product to sell to those potential target markets, and drafting communication strategies and general marketing campaigns, instead of collecting data by talking to other people in and out of the building.
It really is possible to go from idea to MVP within weekend, and more entrepreneurs should be doing it
The act of turning an idea into an MVP that you can present to other people, getting them interested in your MVP, and even getting them to pay you a single dollar — heck, maybe even five dollars — as a signal that they place some level of monetary value on your MVP, is an exciting, inspiring, and very doable activity.
However, the idea of presenting a subpar or unfinished product to someone else with the intent of soliciting their feedback and even a potential early sale can be very uncomfortable and embarrassing. I gather that this may be especially true for those aspiring entrepreneurs who have already achieved some level of career success at larger companies with more structure and a well-established system for selling a product to customers only after it’s 100% complete. That said, for anyone who puts their heart, soul, and money into their creation, they may understandably believe that their product is a reflection of who they are, their skills, their experience, and even their intellect.
How demoralizing and utterly futile must it be to present something subpar, only to have other people quickly deride it…right?
Turns out, not demoralizing or utterly futile at all. Quite the opposite, presenting a subpar MVP gave us highly useful insights into what future iterations of our product should and shouldn’t include and helped us identify more appropriate target markets to approach.
Furthermore, Startup Weekend provided us with a low impact training ground to experience creating and using an MVP (based on the customer insights collected) to generate a list of potential customers and even close a few initial sales — something I never expected to happen. At the end of the 54 hours, I wound up with a list of potential customers with whom to send updates and even invitations to test prototypes. Not bad for anyone trying to build their customer database and improve their product development process through customer feedback.
The Lean Startup methodology is very useful for these kinds of sprint projects, but not everyone may on board
If you haven’t read Lean Startup by Eric Reis yet, then I highly recommend that you check out a copy at your local library. His methodology of creating a hypothesis about the customers and their potential problems, conducting low-cost (time, money) experiments to test the hypothesis (in our case, short problem/solution interviews), and then using those learnings to hone in on the real problem that should be solved is tremendously useful, especially when working under short timelines like Startup Weekend.
As you might imagine, I’m a fan of the book. However, much to my own surprise, I learned that the Lean Startup methodology can be a very foreign, disruptive, and uncomfortable concept to others, especially to some who come from large corporations entrenched in bureaucracy and politics, or from siloed teams where everyone follows the same traditional work philosophy of planning big before doing anything else.
I remember one particularly terse conversation within our group that occurred just past the midway point of the 54 hours.
During a group check in, one member had insisted on identifying the key decision-maker within the group. A couple of us who had been applying the Lean Startup methodology since the start of the event tried to explain that there wasn’t a decision maker in the traditional sense, but rather that we were going to let the data from our customer interviews make the decision for us.
Unsatisfied with that answer, the questions kept coming: “How are team decisions made?” “Well, who is making what decision?” “So, when we get results from the surveys, then who will make the decision on what we do with it and which direction we go?”
Based on the tone of their line of questioning, this teammate wanted a leader to make decisions, and she wanted to have a say in who that person was. Relying on some intangible entity (data) to guide the team’s trajectory wasn’t exactly a comfortable or agreeable concept to her.
At the onset of the project, agree on behavior, communication, and performance norms
In hindsight, the exchange with the above-mentioned teammate represents a lesson often learned from previous projects yet just as quickly forgotten or easily overlooked, especially in the heat of sprint projects: Get agreement early on how the team will make decisions, how information will be exchanged, and who does what and at what level of quality.
Had our team invested its first thirty minutes into figuring out these norms, then we would’ve spent less time debating strategy and questioning decisions, and more time actually getting things done. As such, it would’ve behooved those members who wanted to apply the Lead Startup methodology to educate the rest of the team on how the methodology works and why it would be the most effective way to approach the next 53.5 hours.
All said, I invested $100 and 54 hectic hours, and I returned home with more practice and experience talking to customers, relaying customer insights to the development team towards the creation of an MVP, and applying the Lean Startup methodology — all of which I’m excited to apply towards my own startup company.