Dont forget to validate your assumptions

There is just so much you can learn from customers (or potential customers) that you should spend at least one day a week talking to them. You'll be amazed at what you can learn.

Technical founders especially love dreaming up cool stuff and getting to coding.

This is a huge mistake.

I recently spoke to one of our customers and asked them what their favourite feature was. I was stunned when they mentioned that sending email when a comment was added was a killer feature for them.

The shock was because we always thought this feature as a commodity feature. I mean, every tool out there has the ability to send email when a comment is added. We had a whole lot of really killer features, but this was one of the key features??

So I probed further.

Turns out that other tools only send out emails for discussions that you are involved in. Our tool sends out emails for everything. Think of a mailing list - you get every email whether you participated or not. Whereas a forum only sends you notification for new replies in the threads where you participated. It was something like that.

We always thought sending email for everything was a limitation. It was on our roadmap to refine it and make it send email selectively.

Well, guess what? Rather than being a limitation, it was actually a feature! And a killer feature for them.

So I called another customer - and this was an important differentiating feature for them too!

In a startup, we make a ton of assumptions. Don't forget to get them validated. Usually what the customer thinks is important is not what you assumed it would be.

Twelve Reasons Why Businesses Fail

From Naeem Zafar's book Seven Steps to a Successful Startup:

1. Solving a problem that most users are not willing to pay to solve your way
2. Thinking that you can do it all by yourself
3. Lacking trust among team members
4. Being overconfident and not questioning yourself
5. Lacking a crisp, singular focus&emdash;Trying to be everything to everyone
6. Marketing myopia
7. Confusing a hobby with a business
8. Pricing incorrectly and not knowing your real competition
9. Failing to properly define your market and customers
10. Not having enough financial resources available
11. Focusing on a market segment too small to sustain you
12. Starting a business for the wrong personal reasons

The difference between a conference and an unconference

One of the things I really like about unconferences is that there is very little "gyan" and a lot of experience sharing. This came home to me when participating in a session on hiring.

The question was: "What strategies do you follow for hiring and building a team?"

This same topic was discussed in a panel in the NASSCOM Product Conclave last year, with some VCs on the panel. In typical panel style, a lot of gyan was thrown around: "Hire only the best people", "Top people create top teams" etc.

That's stating the obvious. I mean which startup doesn't want to hire the best people? Do these VCs believe startups are intentionally hiring poor people because they believe its a better strategy??

The fact is that there are a lot of on the ground challenges to hiring that these panelists are hand waving away with their gyan:

1. Startups are always short of cash and cannot match the compensation in bigger companies
2. A lot of startups hire good guys only for them to leave in 6-12 months
3. Really good guys are hard to find
4. Most employees are not interested in stock options (a lot of Silicon Valley returned VCs talk about stock options... one wonders if they have actually recruited in India)

At the end of the panel, the audience is usually unsatisfied. The panelists tell them what they already know without a word on tackling ground level challenges that they face.

Now compare that with an unconference. Once more this topic came up at the TiE unconference.

Look at the answers this time:

1. Many top people are around in smaller cities, who are not taken by big companies because of a lack of english skills. They are smart and make good startup employees
2. Find a few people who believe in your vision and then complement them with freshers
3. Look at 6 month internships - lots of smart people available as interns
4. Look at your requirements - not all types of work require the best people. Some types of work are repetetive and may just make good employees bored.
5. Look at the attitude and teach the skills

These are strategies that are coming from the experience of people who actually have to tackle these on-the-ground problems. At the end, the participants feel charged up with ideas to take back and implement the next day.

This is really what makes an unconference different for me. The focus on real solutions to real problems is invaluable.

By Siddhu (S3)

3 Oct OCC Meetup Roundup

We had the October 2010 meetup of the Chennai OCC. Tony Aug, VP IT of Sanmina had come down to attend the meet. Once of the big problems startups often have is understanding how large enterprises make decisions. This is really important in the context of B2B enterprise sales. So it was really good to have Tony come down and talk about the executive perspective when purchasing software.

Some points from the meetup -

• The #1 reason for purchase in a recessionary environment right now is to cut costs. If you can show substantial cost reductions, then that is a big win.
• Many cloud/SaaS startups dont understand the security and privacy needs of enterprises. Eg: A company like Sanmina with operations in 20 countries need to run only on certified infrastructure that comply to EU security and privacy regulations, HIPAA, and a host of other regulations. Startups right now cannot guarantee all this
• Pricing: $10/user a month sounds reasonable, but multiply it by 50,000 users and it becomes huge. So you will need to find a way to get it into the team on one pricing model and then switch to another pricing model (possibly a flat price) when rolling out to the whole organization
• Dont forget about switching costs. Once an organization has spent tons of money on training and integration, it is unlikely that they will switch over, even to a superior product, unless there is a really easy path for them to do so
• Subscription pricing is great because it allows organizations to get started without expensive capital expenditure. The old model was to buy expensive servers, install expensive software, training, integration and then you could look to get RoI. The new model is to subscribe and cancel if it doesn't work out
• You can expect a small team to pay by credit card, but larger orders will need a purchase order and go via the purchasing department. Once that happens a lot of other stakeholders will look at it and question the need for the purchase. So you will have to answer to these other stakeholders too.
• Lock-in is important in a subscription service. Most companies will want to be sure that they can get their data out at any time
• Sanmina is a huge believer in open source - cuts costs and there is a community to help. For mission critical systems they pay for commercial support
• Escrow: Larger companies will usually ask startups that the source code be put in escrow. In case the startup closes down, the company gets access to the source.
• Using tools like Linkedin, it is really easy nowadays to find a path to get to a decision maker in any company

By Siddhi (S3)

Sales Stories!

This post is the first in a series of stories on selling.

This stories in this post are from the book Hope is not a strategy.

On targeting the pain point

    Early in my sales career as an account manager, I was in the back of the room while one of my product specialists was presenting a system. We were extremely proud of the functionality and about halfway through the presentation, our product rep put up a slide and said, "Now, if you were a hospital, you'd really like this feature."

    What!? I was utterly stunned. I thought to myself, "They're not a hospital-they're a bank! They're never going to be a hospital; they'll always be a bank!"

    How preposterous, the idea of showing a hospital feature to a bank.

    But this is no less preposterous than showing somebody a solution to a problem they don't have-or a feature for which they have no need. You might as well show a hospital feature to a bank.


On trust

    The evaluation process was grueling. Two vendors were pitted against each other and were required to do detailed benchmark implementations in the evaluation of their products. It was an exhausting, detailed process with perhaps twelve to twenty people on each vendor's side.

    In the end, we won by a couple of points, but we broadened that advantage into a business partnership. Their executives met our chairman. We had a corporate visit. We continued to talk about implementation and support and widened the gap. We actually reached a measure of business partnership before they signed the contract.

    At dinner the night before the contract signing for multiple financial systems, the client said, "Oh by the way, do you have a fixed asset system?"

    "Certainly"

    "How much is it?"

    "Seventy-five thousand dollars."

    "Add it to the proposal."

    I thought, "They just bought a system sight unseen. How could they have required such detailed evaluation in the beginning and now they have bought a system they never even looked at?"

    But they went further.

    They added the graphic user interface for all the systems, which they knew was in the prototype phase. There were no references for this three-hundred-thousand-dollar product at that time. The opportunity went from six hundred thousand dollars to almost a million dollars, and forty percent of it was on products they had never seen.

    How could they evaluate in the beginning in such detail and buy products sight-unseen now?

    The answer is trust. They trusted our products based on the ones they had evaluated. If those worked, then these must. They trusted us as a company because they had met our top executives, they'd been to our headquarters, and they knew we were a stable industry leader with a good track record of delivery. And they trusted us personally because we understood their business and we had become friends.

By Siddhi (S3)