“Team X needs a developer! Any developers left?”
If you’ve been to a Startup Weekend event that probably sounds familiar. If you were part of team X, it also probably means you failed at networking. There were 30 developers in the crowd – how many did you talk to? How many heard your pitch?
At the first Startup Weekend I attended I only talked to about 4 people before the pitches started. Coincidence or not – my idea got only 4 votes. At the next one I tried to meet as much people as possible. The idea that I pitched was one of the top voted ones. See the pattern there?
I’m a developer at heart. I prefer interacting with software instead of people. I am “socially challenged”. I did learn a few tips and tricks that helped me overcome it though. Of course, they apply to any kind of networking, not just Startup Weekend events.
1. Don’t sit down
If you sit down (at a table for example) you’ll only talk to your neighbours. You’ll also be less accessible to other people. You don’t want that.
The fastest and the cheapest way to validate if the potential customers really have the pain or need you think they do is to have 15 minute talks with some of them (just make sure they actually fit the profile).
You want honest feedback and information. You won’t get it if the person in front of you is trying to determine whether he or she needs your product.
In fact, don’t even tell them your idea (yet)
You don’t want bias in their replies. And they will be biased if they know your idea, consciously or unconsciously applying it to their case.
Ask open-ended questions
Don’t do a survey. You have access to a real person – find out his or hers experiences and feelings, that will give you way more information than some preset answers.
Or tell me what it is in 12 and sell it to me in 6. Whatever works best for you.
When describing the product, be clear on what it does and who should use it. Don’t leave me guessing what your product does and if it applies to me.
For the selling part, be creative. How would you capture the interest of a person that fits your client profile using just a few words? Stay away from generic taglines like “the best X in the market”. Make me react, make me click.
Because you have less than a second to impress a potential client arriving at your landing page.
Because that’s somehing you can fit in a Google or Facebook ad. You’ll want that.
Taking full advantage of mentors, especially during intensive events like Startup Weekend, depends a lot on the capability of the team to receive mentoring. So, here are a few tips & tricks to ensure you’ll take full advantage of your mentoring sessions.
Gabriela Enrigue mentoring in SW Aguascalientes
Not all the things the mentors say to you are to your liking. But getting into a debate will not help you. Listen and take notes.
2. Look for actionable advice
Is he/she telling you to do more customer development? Or to release a prototype ASAP? To investigate your competition? You should leave with a task list.
3. Be honest
Answer the questions honestly and to the point. You have nothing to gain if you try to look smart by dodging the question.
4. Don’t sell
The mentor is not your client. So why would you try to sell your product to him or her? Don’t look for validation of your idea with your mentor. You have your (potential) customers for that.
Corollary: the mentor might not be convinced by your product, but then again, he is not your client!
If you ever had to convince a client or a boss why Agile works, you know that it’s not an easy task. Agile goes against many ideas that are considered axioms in the business world – like planning first and then keeping to that plan: “plan your work, then work your plan”. If that is the case, these points from a talk by Martin Fowler and Neal Ford (ThoughtWorks) might help you.
In the Plan Driven approach, a project is successful if it goes according to plan, so in software development it depends on requirements stability, on having clear and fixed requirements. As you probably know, that is a luxury most software projects don’t have, and a first approach would be to apply techniques like Change Management or Sign In Blood to contain the changes. Unfortunately that leads to unhappy clients and unusable software.
The Agile approach is to break the dependency on requirements stability and come up with a process that takes into account changes. It does that by using Adaptive Planning and Evolutionary Design.
Adaptive planning implies going through the project cycle many times, re-planning and re-adapting often.
Evolutionary design can be achieved with the help of practices like Self Testing Code, Continuous Integration, Refactoring and Simple Design.
If this made you curious, I highly recommend that you view the complete talk here: