Perspectives on Relevance: Why Endurance Beats Speed

Last golden puzzle piece to complete a jigsaw., representing problem solving for Perspective on Relevance story.

I recently gave a talk to a group of new hires here at Adaptive Insights, and one topic we discussed is how much of the original thinking and design behind our software has held up over time. While this is a testament to strong design in our early days by a group of seasoned engineers, the driving force was primarily the foresight and perseverance of our founder (and chairman), Rob Hull.

Thirteen years ago, he sat down with our engineering team to talk about the crazy challenges that companies face during a typical chaotic budgeting process. We were all ears. Rob had a vision for a product that could simplify and streamline budgeting, and that would make it easier for colleagues to collaborate.

Does speed to market really matter?

Even as we listened, the team’s mental engines were revving. We were eager to start problem-solving. But sometimes hurtling out of the gate can cause even an innovative idea to sputter out, years down the road. Sprinting toward a solution might mean a quicker launch date, but it can also mean designing a framework that only works for some industries or companies of a certain size. And does your speed to market really matter if the product can’t scale beyond the original niche market?

It may seem hard to imagine a future in which thousands of clients—from Silicon Valley startups to multinational mining companies—use your software. But Rob encouraged us to do just that.

He knew we needed a flexible solution if we wanted to grow beyond one niche audience. Rather than building a Barbie Dream House to sell to clients, we needed to design Lego sets, which could be used to build anything from budgeting bungalows to castles. And while architecting a finance tool tailored to software-company clients would have been the easiest and speediest path, it would have hamstrung our growth later. Hasty early decisions might yield a framework that was clumsy to build upon down the line.

Designing software that works as well for five clients as 5,000

So from day one, we set our sights on designing software that would work as well for five clients as 5,000, and as well for a midsize retailer as a multibillion-dollar healthcare company. As we created the software’s underpinnings and wrote and refined the code, we also built in pauses—time to ask: Will this work for everyone? What industry-specific assumptions might have crept in here? How will this feature or that server function when we have 10 customers or 1,000 customers?

For instance, our team had worked with multiple databases in past jobs. But we decided to use Oracle as our back-end database because we knew it would scale as we grew—as well as provide us with the stability we needed, no matter our size. And we picked Linux as our operating system, in part because of its proven ability to scale.

Continually evolving and improving our software

Since those early days, we’ve continued to evolve and improve our software. We’re now handling larger data sets and even more parts of the business planning process than we ever imagined. Which proves that thoughtful, measured steps—not speed—will help you build a company that’s still relevant long after the launch.

So, as Adaptive Insights and I both approach our 13th anniversary, we are still enhancing and expanding software that uses the same structure and approach as it did on day one. For that, I raise a blog toast to the man who insisted it be this way: Here’s to you, Rob!

Mark Thompson is chief architect and a founding engineer at Adaptive Insights.

Visit the Customer Success section of our website to learn how companies are using Adaptive Insights to transform FP&A.

Share this: