How we reduced our time-to-production by 90%, and quadrupled our velocity

Towards the middle of Q2 2013, I took over the responsibility of leading our product(s) along with Dave who took on the responsibility of managing our development team. For a development team of less than 10 developers, the challenge ahead of us was very clear

• We were doing ~ 5-10 releases a month across our product stack
• Our average elapsed time from conceptualizing a feature or improvement to delivery in production was ~ 100 days

Our mandate was to deliver value to the users faster by accelerating the rate of releases, and drive down time to production as much as we could. Essentially, we wanted to become more responsive to the needs of our customer & the business

The Old World

While there were many areas of improvement, I list what we noticed as top characteristics of our development process

• Developing user stories, use cases & scenarios - Our product management served as strong proxy for the customer & diligently detailed user stories & use cases to help the developers learn of our customers’ needs. This was the reasonable thing to do as our product requires significant input from domain experts, and prepping use cases to help developers understand the problems our customers want to solve.
• Strong competence in specific areas of our stack - Our developers had cultivated significant competence across clearly identified areas of our development stack. Again, like many teams, we matched skills to areas of code. This allowed us to move the respective areas of code faster & faster over time
• Quality assurance by QA team & product management before shipping - We had developed a culture of quality assurance as the last gate of development before shipping to the customer. This allowed us to catch areas where we hadn’t met our customers needs, or the user story wasn’t completely satisfied before shipping the product. This is difficult to argue against.

As strange as it may sound, these were the very practices that held us back. Let’s look at them up close

• Developing user stories, use cases & scenarios – On face, this is a very good idea. However, this abstracted our developers from the customers which made it difficult for our developers to understand the pains of our customers. The answer here was clear. We needed to move our product team’s center of gravity closer to the customer, and eliminate product management as a bottleneck. Instead, product management would serve as a bridge to the customer, not a gatekeeper.
• Strong competence in specific areas of our stack – This worked very well for us in the early days. However, given that everything we ship is cross functional, we needed developers from every area of code to ship anything. This led to key man dependencies that bottlenecked our development efforts.
• Quality assurance by QA team & product management before shipping – Since product management had the best understanding of our users’ problems, this was considered an important & critical step. Product management would request domain experts on our team to validate the product against expected behavior prior to shipping. This led to significant time added after development & prior to shipping.

The New World

We developed principles that we would follow to break away from this practice & reduce our time to production while increasing our velocity (as measured by # of releases)

• Move our center of gravity closer to our customer – The purpose here was singular. We needed our development team to have a visceral understanding of our customer’s goals & pains. We did this by holding multiple seminars on architect’s workflow as well as building physics in-house. In parallel, we started conducting user interviews & usability sessions – the caveat being that the latter would be led by our developers, coordinated by product management
• Reduce batch size – We decided that we would work relentlessly to minimize the quantum of product enhancement that can be meaningfully sent to our customers. We also made commensurate moves across our technical stack to facilitate this
• Decentralize releases – We wanted developers to be responsible for shipping the product, right from the stage of conceptualizing the ticket to release. This could only be done if we reduced the size of each release, product wise, to something that could be managed by a developer. Further, it required our services to move independently of each other when needed.
• Enhance code coverage – We decided to make conscious effort, even at the cost of near term benefit, of sharing code across the team. This was done to allow multiple developers to move code across the stack.

The result, thus far

Time to production vs. creation date

• We drove down our time to production (defined as time from conceptualization to production) from 100 days on average to 10 days. As a result, we are now very responsive both to our customers' needs and our vision for the product.

# of releases per month

• We have nearly quadrupled the number of releases we do. This really paid off for us in Q4 where we launched 2 new products – Sefaira for SketchUp & Sefaira for Revit, and did multiple releases which benefited our customers.
• In terms of code coverage, 80% of our developers contributed to areas of our code where we invested 80% of development budget

While many challenges lie ahead of us in terms of driving growth, it is encouraging to note that we are accelerating our product development. Our customers & investors expect nothing less.