“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.
Sitting down makes you look inaccessible
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:
Pourquoi, pas comment
USI 2010 : conférence incontournable du l’IT en France
Rendez-vous annuel des Geeks et des Boss souhaitant une informatique qui transforme nos sociétés, USI est une conférence de 2 jours sur les sujets IT : Architecture de SI, Cloud Computing, iPhone, Agile, Lean management, Java, .net… USI 2010 a rassemblé 500 personnes autour d’un programme en 4 thèmes : Innovant, Durable, Ouvert et Valeur.
Plus d’informations sur www.universite-du-si.com
In Visual Studio 2010 you can use xdt transforms to fill the web.config files with the appropriate values for deployment to test or production environments.And it is pretty simple to use:
- - add Config Transforms to the web.config (like web.Debug.config)
- - duplicate the sections with the values you want to customize
- - set the xdt:Locator attribute for the nodes that need to be identified by an attribute (like xdt:Locator=”Match(name)”)
- - set the xdt:Transform to control how the values are changed (common uses – xdt:Transform=”SetAttributes” to update some attribute values, or xdt:Transform=”Replace” to replace the whole node
- - you get the transformed web.config when publishing or creating a deployment package (or you can create it from command line).
More details on how to use the Web.Config Transformation here.
However, there is a nasty bug that you won’t probably notice before publishing for the first time.
Let’s say that you want to replace a value that is not an attribute, but the inner text of a node.
<value>Default value here</value>
You can write the transform like this:
<value xdt:Transform="Replace">Production value</value>
The problem is that in the generated web.config file the value will appear like this:
The extra spaces (and newline) will be passed to the value and can generate problems if the setting represents a file path for example.
According to Microsoft, this is a known bug and will be fixed in the next Service Pack for Visual Studio.
The workaround is to trim the value before using it in code, but that won’t help you if the setting belongs to a 3rd party component that you can’t modify.