I remember when it was easy to make user-centric decisions. That was in 2015, and at the time CallRail only had a few hundred users under its belt. Cue the dream sequence, everyone! Four years ago, our CEO Andy Powell needed call tracking software for his startup, Bimmershops. Back then, call tracking technology was limited to companies with deep pockets. Marketplace services were expensive (especially for lower volumes), and implementation and management were so complex that users typically required extensive training. Andy and Kevin Mann created the original CallRail application for Andy's use case and began buying it from other companies like his. At first, our users were in a consistent, beta-style feedback loop. As the team grew to include support agents, we blocked out a portion of every company meeting to discuss "what customers were saying this week." This way, everyone in the company received weekly updates on our users' top goals and issues.
When I joined in 2015, we were still creating a product roadmap heavily inspired by user requests, and we were still receiving weekly updates from our customer-facing roles. In short, we had found ways to employee email database stay aligned with the needs of our users – the people we were building our product for – but it was going to be nearly impossible to scale that approach. Over the past 4 years, our business has evolved rapidly. We were still “dogfooding” (using our product internally), but our own use cases looked less and less like our small business or agency users. Pretty soon, we had to work harder and harder for the roster that we previously took for granted when our entire team gathered around a conference table. CallRail had already achieved a lot by training cross-functional teams and empowering them to create a great product.
But this entrepreneurial approach, which had worked so well when we were little, began to show signs of strain when we hired our 100th employee. We had created a product development culture that relied heavily on leadership and veterans to know what to build and how to build it. Our customers' information was collected and disseminated through what amounted to an extended game of “telephone”, which meant that it was often out of date by the time it reached our desk. We were going fast and making guesses. There were a few features that went deep into production, before a quick registration with a user group invalidated our strategy. We would build a feature for the post and then sometimes go back and make changes based on feedback. So when we started factoring in this refactoring time, it seemed like the time saved by reducing our research phase ended up costing us overall.