subject: How A Start-up's Team Size Is Great For Investors But Bad For Business [print this page] Investors love small teams; they satisfy the current desire for capital efficiency, but large customers have a different point of view. One of the issues that start-ups often face is the size of their team. If the start-up only has around 10-15 people and has developed some interesting technology, the small size of the start-up is a factor in deciding whether to purchase or engage in a partnership. Team size can have a impact on sales.
One question a larger corporation will consider is whether they can develop similar technology. In large companies, projects are always ending and they often have teams waiting for new assignments. Assigning a few people to reproduce the technology will be considered as an option - particularly if the start-up's development team is small. When confronted with external technology, in-house development teams are always quick to respond that they could do that too, so why bother paying an outsider? Start-ups are about four times more efficient than large corporations.
In the eyes of a large corporation, value for the technology and product is often established by the size of the team that created it: the smaller the product development team, the lesser the perceived value. What a corporation is willing to pay for a product is not only determined by the products benefits and features, but also by who made it. When a venture-backed company is confident of a potential acquisition, there is a sudden drive to hire more employees - often doubling and tripling the headcount. The start-up is trying to increase its value in the eyes of the acquirer through the size of the team.
One of my software start-ups had this exact scenario. The Vice-President of Engineering contacted the start-up and invited them to give his team a product presentation. The team was resistant to using the software. Conceptually, it seemed simple, so why not just develop it themselves? This is the DIY attitude of many engineering teams. The VP was thinking about meeting schedules. He knew it would take a lot longer to develop than the team thought, and he didn't have available resources either; hence, the company licensed the software. When the field application engineer was sent to help them install the software and get them started with its use, the field application engineer (FAE) got an earful from the staff. The IT people didn't like being told to install software that they hadn't approved and didn't want. And every time the engineering team couldn't get something to work - instead of referring to the users' guide or asking the on-site FAE - they just complained that the software didn't work. Overcoming concerns with a product from a small start-up doesn't just stop with the sale process, it can continue on throughout the relationship.
At another start-up, a customer insisted the start-up have people in different functional areas respond to their needs. This was a small start-up and it didn't have an organization chart that looked like a hundred year old oak tree. The start-up knew it could meet the customer's needs without all these extra people, so the start-up created employees. It's very easy to do with email and voice mail. As long as John Doe responded via email, the customer was happy. And when John needed to be at a customer meeting, well ... he had a personal emergency or was out sick that day.
Team size can be a difficult objection to overcome. Often the best approach is to only deal with someone at a director or vice-president level. The lower levels are more concerned about an outsider infringing upon their territory, or making them look bad before their superiors. The more senior people are interested in meeting schedules or larger business issues, which are ultimately what they will be judged upon. One way to handle this situation is use the start-up's experience in developing the technology to estimate how long a similar internal project would take to complete and to couple this with the risk factor of getting the DIY project to be of the same proven quality. Most internal teams won't even consider how long it will take to just write a manual on how to use the gadget or how much effort involved in supporting users.
In one of my previous companies, the company sold software licenses for $150,000 each. I always had to justify the price after the prospect realized the product had been developed by a small company of ten people. I would often explain how many people it took over the years to develop and refine the software, and how many customers had used and subsequently ironed out all the flaws. By the end of the conversation, the costly price tag seemed quite inexpensive.
A proposition is attractive to a large company when time is a factor - the solution was needed yesterday, expertise is a consideration - an advertising firm won't have a team of programmers on staff, the problem can't be solved without it - the customer tried to fix the problem, but failed, or it's just easier and simpler to buy the solution.
Copyright (c) 2010 Cynthia Kocialski
by: Cynthia Kocialski
welcome to Insurances.net (https://www.insurances.net)
