← Techstars Blog

This post is from guest blogger Joe Gravante.

1 big idea pitched on Friday night attracted 6 developers, 4 business folks, and a designer to attempt building a product that could save lives (and make tons of money). We had a great plan in place, the technology was viable, and the team was ready to execute. By Saturday at 5pm, 6 of the team members had left the project and the rest of the team was too burnt out to pivot. A lot of things happened within that 36 hours that put us in this situation and the remaining 5 people banded together to discuss what went wrong. Here are our lessons learned:

Do thorough market research early! In any space with opportunity there are bound to be other teams trying to solve the problem. Don’t be discouraged by this, but make sure that you find out all of the players, what their solutions are, and how your solution can differentiate.

Once the project has started and the team is executing, don’t derail the team with unnecessary information. As a product manager, if you discover a product that just seems to kick your product’s ass, don’t stop the show. Take time to think through your product’s strategy and determine how to successfully alter it without grinding the team to a halt. There are bound to be ways to compete but not everyone on the team has to offer their input on how to do it. Focus on keeping the team working through the plan to meet the product goals and get creative on how to alter that plan with minimal churn.

Get an SME in the problem space on your team. Our team was lucky enough to have a person with 20+ years of experience in the health industry consult on our product. They provided more insight and guidance on our product than what we could research online. Even though our product didn’t make it out the door, this person was invaluable during the initial product design.

Build the right team to meet the goals.  Even though people may be interested in working on your idea, not everyone’s individual motivations align. As a team lead, clearly communicate the goal of the team up front when selecting team members. Find out about their motivations for doing startup weekend. On our team, some people just wanted to play with new technology. Others wanted an opportunity to make an easy buck. Some wanted to build a lasting product. Some wanted to learn more about the problem space. On the surface, everyone said they wanted to help make the product a success but once the team started functioning it was clear these individual goals did not align well with delivering on the overall product goal.  Make sure break down these individual motivations and use them as selection criteria for building the best team to achieve your goals.

Put decisions through the team lens. Make sure people are making decisions for team success.This may sound really obvious, but it is critical if you want the team to function at 100%. Our development team chose Python for code behind, when the only common language the team shared was .NET. We found out when problems started arising that the developer who pushed the decision was interested in learning Python that weekend and didn’t concern himself with the rest of the team. The team did not stand up against this decision and it stopped us from moving forward once that developer left the team.

Don’t duplicate roles.Each team members should have clear roles and responsibilities. More heads is not always better if the roles overlap. The energy that goes into coordination and interfacing between these roles takes away from overall team effectiveness.

Make sure that software is the right solution. Attempting a tech startup it’s easy to fall into the trap that technology is the right answer. In our case, our end users were not the most technical savvy and connected, which meant the problems we were trying to solve with software might have landed flat. Use technology for the right reasons, not because it’s cool.

Network, network, network. Even though our product didn’t make it to judging, our team fully realized the value of the people connections made during the weekend. The remaining team still meets bimonthly as a startup group and we have frequently reached out to other teams who were at Seattle Startup Weekend for consultation. Since the remaining team had already gone through these lessons together, it has been easier for us to work together in the long run.

 

Failed is a harsh word – we only failed in getting our project to the pitch floor – these lessons will stick with our team and next startup weekend we will be a force to be reckoned with.

maris