More than 200 people showed up for the celebration, which began with cocktails and a sit-down dinner in “the loft”, a brick-and-beam room that had been decorated with lights and ribbons. After dinner, the attendees moved downstairs to a dance floor, a well-stocked bar and a professional DJ. “The last memory I have of that night was Mike dancing so hard that he slipped backward into a large tub of ice,” says Levi Cooperman, referring to his co-founder, Mike McDerment. “It made for an uncomfortable walk home.”
But for at least one evening, McDerment was able to put aside his growing realisation that FreshBooks had a serious problem: It needed to reinvent itself. Otherwise, the company was facing long-term decline and even death. Ten years is a long time in the life of a software application, and popular as it was, FreshBooks had fundamental design problems that made it extremely difficult to add new features and even do basic maintenance. McDerment knew his was hardly the first company that needed to rethink its signature product. Witness BlackBerry and Lotus 1-2-3. Sooner or later, he realised, a competitor would come along and deliver a superior user experience.
And that’s exactly what happened. In January 2015, a company called BillSpring appeared out of nowhere, offering self-employed individuals online invoicing software with none of FreshBooks’ technical problems. BillSpring, it seemed, was everything McDerment had feared back at that holiday party—but with a surprising twist.
FreshBooks was an open and forward-thinking companyFrom the beginning, McDerment had possessed a keen sense of his customers’ needs—partly because he’d started out as one of them. He had owned a four-person design agency in the early 2000s, and like most owners of tiny businesses, he’d handled everything from sales and marketing to project management and bookkeeping. During one hectic period in 2003, he was putting together invoices in his usual fashion—retrieving an old one and changing the contents as necessary—and made the mistake of saving the document without first renaming it. He realised too late he’d just obliterated an invoice he still needed.
At that point, he says, he snapped. He knew there had to be a better way. But all the bookkeeping programs he looked at struck him as too complex and too filled with jargon. So, using his own, limited programming skills, he put together a simple application that allowed his clients to log in and view invoices online. That application became the kernel of a new business. With the help of a doctoral student in computer science and Cooperman, an electrical engineer, McDerment turned his makeshift program into online invoicing and expense-tracking software for self-employed people who didn’t want to learn accounting.
By mid-2006, the company had almost 1,000 paying customers, and the pace of growth was picking up. Cooperman, in particular, had worked diligently to improve FreshBooks, but he reached a point where he needed more experienced help, and so the company began hiring its first professional programmers, who quickly ran into problems. “We began hearing, ‘This thing is really hard to work with’,” McDerment says. “I was like, ‘Okay—well, whatever’.”
The programmers did the best they could with what they had and were able to make incremental improvements, but eventually one of McDerment’s mentors, who owned a web-hosting company, agreed to send in an associate to assess the situation. After completing his analysis, the associate told McDerment he had good and bad news: “The good news is that you’ve solved the hardest problem. You’ve figured out how to build a business, and you have a product that people love and are signing up for. The bad news is that you guys stink at technology.”
Still, the company was growing faster than ever. “But it was like having friction or waste in the system,” McDerment says. “To build one thing, you had to fix three other things.” He made a couple of serious attempts to “replatform” the software, as he calls it. The first, known internally as Evolve, achieved some results but didn’t accelerate the process of adding features. A second, FreshBooks Next, was led by a new chief technology officer McDerment had hired in August 2012, Warren Faleiro, a native of Toronto who had been working in Silicon Valley for 12 years. Faleiro and his developers kept being thwarted by the deeply embedded problems. Confronting the challenge of having to change tyres on a moving vehicle, they gave up.
In January 2014, a month after the holiday party, McDerment got together with Faleiro and two of his top people. By then, they all realised they would have to build an entirely new product. “Okay, Mike,” Faleiro told McDerment. “We know what you want. Why don’t I send some people up to the loft”—the site of the holiday party—“and see what they come up with.”
When the loft group began meeting, McDerment and Faleiro urged its leaders—Avrum Laurie, the director of products, and Jeremy Bailey, the creative director—to consider experimenting with new ways of working. Bailey took them at their word. The company’s product-development process, he thought, needed to be brought up to date.
In most ways, FreshBooks was an unusually open and forward-thinking company. Every employee received a daily email reporting how many people had tried the software the day before, how many had signed up, what the revenue was. And yet in at least one way, FreshBooks was utterly conventional. Product-design decisions were made strictly top-down. “We used to have these epic sessions with Mike,” says Bailey, the creative director. “I remember when we designed our iPhone app, we sat with him for three hours and went over every screen.”
Bailey believed that had to change. He was already familiar with “design thinking”, an approach to innovation and problem-solving that looks at the intersection of three factors: The desirability of a proposed solution, its technological feasibility and its economic viability. The trick is determining what is “desirable” about this or that feature in a new product. The best way to find out is by asking customers. But how do you get customers involved in product design? Bailey went online and came across a book, Lean UX: Designing Great Products with Agile Teams (O’Reilly Media, 2016), which called for testing ideas and designs with customers every week. “It really clicked for me,” says Bailey, who persuaded Laurie to try it.
Meanwhile, the loft group, which had ten members, had decided they should articulate in detail what a product might look like that fulfilled the three criteria set up by McDerment: He wanted it to be ten times easier to use than the current FreshBooks, to enable collaboration with clients and teams, and to be structured so improvements could be made much faster. Following the Lean UX process, they brought in FreshBooks users to test their concepts. “We showed our designs to one person, and it seemed to be going okay,” Laurie says. “Then he said, ‘Hey, is this the new version of FreshBooks?’ We said, ‘It’s a glimpse of what could be’. And he said, ‘Well, if this is where FreshBooks is going, I don’t want to come along with you guys’. That hurt like a knife to the heart.”
But it also led to a lesson. “We learnt that when you hear something like that, you have to stop yourself from responding emotionally, which is very difficult. You have to push on through and ask, ‘Why? What isn’t right?’ Often you’ll find out it’s something tactical that you can fix easily without compromising the overall design.”
Although McDerment liked the group’s preliminary work, he wasn’t convinced that this attempt to solve FreshBooks’ problems would be any more successful than the previous two. When he asked how long the team thought it would take to create a new version of FreshBooks, the answer was two-and-a-half years. “Absolutely not,” he responded. “If you’re thinking two-and-a-half years, it will take seven. We’re not doing it if it takes that long.”
Forewarned, the loft group moved back downstairs and began building a prototype. A senior product manager, Melina Stathopoulos, formed a scrum team to work full-time on the first part of the prototype, the invoicing function, which wound up taking about three months. Other scrum teams were formed later to build the expenses function and focus on client management. All three teams used the Lean UX methodology.
The purpose of the prototype was to show that the vision could be translated into the kind of user experience McDerment wanted, and in that they succeeded. Faleiro and the leaders of the project again tried to estimate how long it would take to turn the prototype into a finished product. Their best guess now was a year-and-a-half—still too slow.
In Silicon Valley, Faleiro had become familiar with the concept of a “minimum viable product”—a product with just enough features to attract early adopters and begin getting information back from them. It would at least allow them to get something to market faster. But McDerment had reservations: “If you make mistakes with it, which you will, it could cost you the trust of the people whose trust you absolutely must have. When customers leave a software provider, they don’t come back.”
Someone suggested launching the new product in Germany or Australia. Another idea was to release the product through a new entity called FreshBooks Labs, which would at least make it clear that the product was in development. One weekend, McDerment was assessing the risks when a thought popped into his head: “What if we just created another company to compete against us?”
On Monday, he floated his idea by Faleiro and Laurie. “I was shocked,” Laurie says. “It was so unlike any idea I’d ever heard at FreshBooks.” Faleiro wasn’t shocked and immediately began thinking of ways to help the development team get into the appropriate frame of mind, urging them to think of the project as a startup and himself as their venture capitalist: “You’ve got four-and-a-half months. If you’re in the market by then, we’ll give you more money. Otherwise, we’re out.’”
At last the designers and programmers were able to test their product in the market, using the Lean UX methodology, and they learnt a lot. They had tried, for example, to make the program so simple that directions were not needed. Thus there were few written clues about what to do. But the program wasn’t intuitive enough for some customers, who, for instance, put the tax percentage where the tax name was supposed to go, meaning the tax would not be added and users would inadvertently undercharge their customers. “We had to rip out that whole part of the program and rebuild it,” Laurie says.
Whatever frustrations they may have felt, they at least knew their instructions were coming straight from customers. In effect, they had erased the distinction between product development and customer service. Everyone was now in customer service.
“ FreshBooks has always been incredibly intuitive and easy to use.
On February 2, McDerment published an open letter to FreshBooks customers, letting them know for the first time that the company had been building a new FreshBooks for 18 months and would make it available later in the year. He answered what he believed would be the most common questions: Why are you doing this? Will prices change? Will you continue to support the old version? He emphasised that customers could decide for themselves whether they wanted to use the new FreshBooks or stick with what he called FreshBooks Classic.
In February, BillSpring’s customers were informed that their service was now FreshBooks. When they logged in, they found themselves on a new FreshBooks website. There were no complaints. In March, scrum teams began testing the new FreshBooks with 5 percent of the people who came to the website for the first time. The teams wanted to see how prospects who came looking for FreshBooks differed from those looking for BillSpring. “They were a little more sophisticated, and their businesses were more mature and needed more from an accounting product,” Laurie says. “So we learnt some new things to do that we couldn’t have learnt at BillSpring.”
By then, Stathopoulos, the former leader of the invoicing scrum team, had put together a whole new group of designers and programmers to manage the rollout. They came up with a plan to coax customers to make the switch by offering them sneak peeks at the new FreshBooks. When a customer decided to give it a try, she believed, the transition had to be quick; if it took more than a minute, customers would give up and go back to the classic version. Because the new program was still being developed, Stathopoulos and her colleagues decided to divide the customers into “cohorts”, based on how they had been using the classic version and what features they needed. A cohort would then be invited to try the new FreshBooks only when the program had everything they were accustomed to using. Thus the rollout happened in stages, and is still continuing. When given the choice, says Matthew Baker, vice president of strategic planning, the majority of FreshBooks customers have chosen the new FreshBooks. “All told,” Bakers says, “the results are positive, but we still feel there’s a lot of work remaining on this journey.
Ultimately, McDerment pronounced FreshBooks “ridiculously easy to use”, and professional software reviewers seemed to agree. “FreshBooks has always been incredibly intuitive and easy to use, and the new version is even more so,” wrote Chelsea Krause in Merchant Maverick. Most important, FreshBooks was now able to add features and make improvements on a weekly basis.
And the project delivered larger rewards as well, some of which couldn’t have been foreseen. “It changed the DNA of the company,” McDerment says. That happened partly because the members of the BillSpring team “forgot FreshBooks”, as Faleiro had urged them to do. By becoming a separate company, they felt free to take risks that they probably wouldn’t have considered had they still been thinking of themselves as FreshBooks employees.
But mainly the DNA changed because of the completely different way people worked, first at BillSpring and then at FreshBooks as a whole. By the end of 2016, all of the company’s product designers and programmers were working in scrum teams, which were in contact with about 2,000 customers a year. That integration of customers into the product-development process gave employees a new perspective on their work. “We were always close to our customers,” says product manager Adam Davidson, “but the intimacy we’re able to garner out of this process is definitely new.”
The company has continued to grow rapidly and expects its annual revenue to surpass $50 million this year. The whole project, McDerment estimates, wound up costing more than $7 million.
Was it worth it? For one thing, he no longer doubts FreshBooks’ ability to survive. But beyond that, he says, the BillSpring project elevated the entire company. “Before, we had a strong product, but I don’t think we would have considered ourselves world-class, although we wanted to be. It took BillSpring to get us there.”
25 Forbes Small Giants
This is Forbes’s second annual list of Small Giants, 25 companies that value greatness over growth. They aren’t opposed to growth—just to growth at all costs. We picked 25 businesses that have sound models, strong balance sheets and steady profits—all privately owned and closely held. They contribute to their communities. They have been acknowledged as outstanding by others in their field.
And they do things any business can learn from.
(This story appears in the 09 June, 2017 issue of Forbes India. To visit our Archives, click here.)