Company Clock Speed

I am a strong believer in customer-driven company development.  The need to establish product-market fit via an iterative set of engagements. Each engagement helps to both understand the market need, while providing valuable input into the product development process.

One major issue, however, is that the cycle time for customer responses is 7-10x faster than the product release cycle time. As a young company, it really pays to be highly responsive, but it does not pay to whip-saw the product team for one-off features. While the features may eventually help you win, the changing requirements and fire-drill time lines do not support quality software development.

Many start-ups end up with bad blood between development and sales - whereby sales keeps saying yes irrespective of the pain and timelines such promises will bear on the company at large. And, they need to say yes to help win, validate the product, etc.

As ClickTurn took off, the two timelines and clock speeds became an issue.

Specifically, we release software every Tuesday, while customer requests require intra or over night turn around. 

To address the need to be customer and market driven, while protecting the engineering process, we developed an internal services team. The services team and the engineering team defined an extensibility model that allowed us to address the vast majority of custom deliverables via an API. The API, and its iterations, allowed two teams to operate at different clock speeds - each focused on hitting their goals; for engineering, 70+ weekly on-time releases, for services, extremely high client satisfaction and customer success.

Moreover, the extensions ultimately improved the quality of the platform and the robustness of the API.

A social contract based on allowing each team to finds its optimal rhythm via APIs or extensibility models helped us reach our customer-driven development goals while keeping (largely) sane and both teams highly productive.