Wednesday, July 28, 2010

A friend told me about an anecdote of a start-up that was obviously heading in the wrong path. The company was quickly loosing money and yet the market was huge. The CEO fired the head of sales and marketing and decided to manage the department. Luckily, they had one thing in their favor, a lot of data. After some analysis and data mining, they realized that the B2C business model was no sustainable. Worse, there were signs of this about a year ago (sales plummeted). They did a small market research and talked with the customers. At the end, they found out the following based on their analysis:

Accounts receivables were taking a nose dive

There were several disruptive technologies and the market had changed

Customers were unhappy with the current business model (the payable from our customers were lower than 70%)

The B2C product had become a commodity and the only way to compete was through money (lower profits)

Customers were looking into a more enterprise product

At the end, the company decided that a new product was needed. A product focused on B2B. With a small pilot they were able to "test the waters" and provide a successful use case. They are now selling the product and making sure that the same mistake doesn't happen again.

I've seem this type of behavior in current businesses. I'm a believer that when you get encountered with this type of issues, departments try to tackled it by using "brute force". I don't believe that this company's sales and marketing department were oblivious of the problem. Instead, I believe that they were just sticking to their strategy. They were too caught up with the every day details of trying to maintain their quota and get more customers. But, they didn't have the pulse on the market. In other words, no one checked if the business model was working.

A few weeks ago, I sat down with a founder of a company which I respect very much. The company was founded by three individuals. He was the COO, another founder became the head of sales, and the last one was a series entrepreneur. He explained that most of their success was mostly due to the management style of the sales manager (company started about 4 years ago and it was worth above $44 million). They called it, "One Hundred Days". Senior management would come up with a goal for the entire company that needed to be executed in the next 100 days. Then, whatever decision, customer, sales had to answered the following questions:

Is this according to the plan?

Would this get us closer to the plan?

Lets check the plan again.

I really like the idea. However, I would add a check and balance approach. You can easily loose focus in the every day task just like the head of marketing and sales in my friend's company. It is what Eric Ries calls "the pivot point".

Pivot is the ability to change direction in response to failure. Within every failure is a good idea waiting for the right circumstance or application. Pivot is an incremental and "zig-zagging path" towards the right market fit. The faster the pivot, the more likely a startup will find success before running out of money.

Ries contends that startups must be "built to learn", meaning validated learning about what customers want has to be the unit of measurement for company success. Turning ideas into products, and testing those ideas against reality, allows the company to pivot effectively, enabling customer-centered testing to be done by the dozen, or even, by the hundred.

A few months ago, I read a blog You're in a Museum by Steve Woodruff. He explained, the fact that there is always room for improvement and we should constantly try to seek for better solutions. He proposed to start thinking in different direction by asking the following questions:

What is actually not working?

What is missing and should be created?

How could this be better?

What new connections can be made?

What do I want to leave behind as a legacy?

How can ideal become real?

What would I REALLY want to make happen if there were no limits?

Why? And, while we're at it - why not?

In other words - question the status quo. We need to know when to change course or when our strategy is no longer working.

Friday, July 23, 2010

I've been playing with Groovy and Grails for the past month. We had a demand of a few sites that needed to be constructed. The sites were small and needed to have some basic CRUD method and a small business rules. Then, we had to tie it with our SMS Gateway that we have developed. We evaluated a few languages, but at the end we chose Groovy for the following reasons:

Dynamic language

It sits in the JVM

Easy to develop sites

We have been playing with the following versions:

Grails 1.3.3

Groovy 1.6.0_20

I have the most respect for the team who build this programming language. The language is very easy to read and the learning curve is very small. The integration that they did with Java, Spring, and Hibernate is very nice. The ORM tool that they created, GORM is very nice and very easy and quiet frankly it's my favorite.

You can sort automatically within the mapping closure. In this example, all queries to the Post object will return in a descending order.

We use the map style of belongsTo, where we create a bidirectional link between User and Post classes. This creates a new field on Post called user that is the bidirectional mapping back to the owning User

Another useful technique is the validation of the fields. In the constraint closure you can specify the fields that need to be validated and the validation type. For example, in this case, content cannot be blank (null or empty).

The first deployment that I made was using "grails war". The con of this approach is that I look the dynamic compilation. So, if any change to the code, you would have to create the war once again, and deploy it. You gain performance but you loose the dynamism of Groovy. If performance is not a big issue, you can use "grails run-war". According to the documentation:

This is very similar to the previous option, but Tomcat runs against the packaged WAR file rather than the development sources. Hot-reloading is disabled, so you get good performance without the hassle of having to deploy the WAR file elsewherthe application is compiled with Java native code. Therefore, every change that I have to make I have to do it in Grails and deploy it once again.