BARREL

For a long time, we, like countless other interactive design companies, dreamed of building and growing a subscription as a service (SaaS) product that could generate recurring revenues. The fantasy was to replicate the success of a 37signals or a Rocket Science Group, two former client services companies that bootstrapped their products into recognized brands: Basecamp and MailChimp, respectively.

The prospect of having predictable cash flow (via monthly or annual subscriptions) was alluring versus having to continually land new business to keep the lights on. We also loved the idea of focusing on just one product and making it awesome rather than juggling dozens of projects and rushing to finish each one under deadline pressures. And we wet our lips at the thought that we wouldn’t have to deal with demanding clients or sit in on long calls and meetings. The grass seemed very green on the other side.

The Start of ProjectFlow

It took us a while to come upon an idea that we wanted to turn into a product. When it did come, it came about in an organic way. It was a simple idea that scratched our own itch: the problem of tracking many projects in one big-picture view. Rather than writing them on a whiteboard or keeping a Google Spreadsheet document, we decided to create a colorful drag and drop interface with customizable columns. We called this Projects Under Management App (PUMA) and built a rough prototype over a weekend. Our clients who came by our office were impressed and asked if we ever considered releasing it to the public. In late 2011, we decided to go for it and blocked out chunks of time for some of our team members to work towards a productized version of PUMA. We named the web app ProjectFlow.

After finding enough pockets of time, we finally released ProjectFlow in May 2012. Because we didn’t have the time to build in a subscription module and hadn’t yet thought of the business model, we began with a free account offering (note to self: don’t launch with free next time). Without spending too much time on marketing, the site started to pick up users, which we saw as an encouraging sign. On some days, especially when a blog review went up, hundreds of new users signed up. We installed Intercom to send and receive messages from our users and quickly learned that many people wanted multiple boards (we only offered a single one) and the ability to share their boards with others. We decided that the ability to have multiple boards would be the differentiator between free and paid plans. In late 2012, we started work on the next big release of ProjectFlow that would finally allow us to make some money on the product. The hope was to have something by early 2013. It took seven months longer than we anticipated.

The Internal Project Problem

Tracking the Investment

I’m not going to frame too many things as “I should have done this or that,” but I’ll note some things that perhaps others in a similar situation may find useful. One of them is the task of tracking and reviewing the amount of money spent on the project and figuring out the return on our investment, especially one that has little to do with our core client services business. We neglected to set clear milestones and budgets for this project and instead hoped that a few spare days here and there would amount to something cool. We told ourselves that even if ProjectFlow didn’t hit it big as a commercial success, we could categorize it as a learning experience and that the knowledge gained from this would allow us to do more lucrative work with clients. We also reasoned that the publicity we generated through ProjectFlow would help in landing new clients. These things all sound good in retrospect, but we didn’t set up any ways to measure the outcomes. What we do know is that over the span of 2 years, we’ve spent more than $100,000 in personnel costs, hosting, and other expenses to bring ProjectFlow to life. What we do not know is how much of what we learned in ProjectFlow actually contributed to other projects. We do know, however, that no new client business was generated through ProjectFlow.

What made us oblivious to the expense of the project was that it was spread out over a long period of time and shuffled with the rest of our internal activities like writing proposals or filling out performance reviews. Because we classified it as an internal project, we didn’t go through the motions of properly allocating a set budget. As a result, even though the project was delayed multiple times and not generating any revenue, we had little idea what we were spending and didn’t feel the pain.

Team Involvement

I’m happy that our Senior Developer Kevin Kneifel has been a staunch advocate of ProjectFlow and the one consistent person working on it from the start. Kevin’s been responsible for the web app’s architecture, database management, front-end, and back-end. He’s made the most of the small pockets of time in between client work to build out the product. Unfortunately, because the immediacy of client work has always seemed to trump internal projects, ProjectFlow has often been relegated to the back burner. This has meant slower update cycles and delays in addressing bugs that hamper our users’ experience. I know Kevin’s been frustrated at times, and it’s always a bummer when we tell ourselves: “If only we had some more time for ProjectFlow, how awesome it could be…”

Early on, I made the mistake of not properly assigning a designer to the project, so I often resorted to asking semi-free designers to help on different parts of the site. As many as five different designers touched ProjectFlow at some point. I don’t think this took away from the quality, but it did dampen people’s sense of involvement and ownership as the project switched hands so many times. In recent months, I’ve tried to make a conscious effort to keep ProjectFlow firmly with one designer (our very talented Jan Cantor). As for project management and testing, having our Producer Diane Wang and Web Ops Analyst Angela Hum on the project has also made a big difference.

Assembling a cohesive team early on with a mission and set of short-term and long-term goals is a big takeaway and something I strongly recommend.

Because the project started small with just myself and Kevin, we relied on a dyadic communication model. I would find help where needed (testing, UX, visual design) and work closely with Kevin to make things work. This made it difficult to transition to a small group communication model, but we eventually switched over from one-on-one IMs to posting messages on Basecamp and making sure everyone knew what needed to get done. Assembling a cohesive team early on with a mission and set of short-term and long-term goals is a big takeaway and something I strongly recommend. This will ensure that everyone involved is in the loop and bringing both ideas and accountability to the table.

Lack of Focus

I’ve experienced several exciting moments with ProjectFlow in the past two years: witnessing over 10,000 sign-ups from all over the world; receiving emails from users that ProjectFlow is an integral part of their daily routines; and finally seeing our first few paying customers. But with the highs have been the lows: the frustration at our inability to push updates faster, the high abandonment rate of first-time users (Intercom is great for tracking who actually uses your product after signing up), and the lack of motivation in marketing the product. This last bit has been unfortunate because I truly think many people could benefit from an easy-to-use product like ProjectFlow. But between marketing ProjectFlow and working on business development for Barrel, I’ve found it hard to bring myself to devote real chunks of time to managing blogger outreach and generating PR. And wary of how much we’ve already spent on ProjectFlow, we’re hesitant to spend on any non-product development costs. This lack of focus on my part, I know, has kept ProjectFlow from reaching its potential.

The Big Picture

The last bit about my lack of focus raises a bigger question: did we go about ProjectFlow in the wrong way? Should we have set clearer goals and expectations? Should we have either bet on the product more aggressively, investing more significant chunks of time and resources? Or should we have pulled back sooner and kept our focus squarely on our core business, the business of client services?

For too long, I viewed client services as a second class business model, one that would be fairly easy to start up but one that would have difficulty in scaling. What I didn’t see was the potential for a well-run and very profitable business that positioned itself as an expert firm and was treated with respect by its clients.

One thing I’ve realized more clearly in the past few months is that being in client services does not mean we don’t get to work on a product. In fact, a strong client services business is all about having a great product. This product isn’t a subscription-based software but rather a really tight process framework with various tools and activities that have been proven and tweaked over time. For too long, I viewed client services as a second class business model, one that would be fairly easy to start up but one that would have difficulty in scaling. What I didn’t see was the potential for a well-run and very profitable business that positioned itself as an expert firm and was treated with respect by its clients. My priorities have definitely shifted towards this goal, and it’s increasingly marginalized my attention for ProjectFlow.

What’s Next for ProjectFlow?

This isn’t a long-winded announcement about pulling the plug on ProjectFlow. In fact, we still hope to attract more paying customers and to enhance the product, albeit slowly. Perhaps the product will get to a point where it can stand on its own with minimal support while helping us recoup partially on our investment. Or maybe we’ll find an enthusiastic partner who can take it to the next level. For all the challenges and hard lessons, I’m very proud of ProjectFlow and what our team has been able to accomplish with such severe time and resource constraints.

Running a SaaS product business is just as much hard work as client services. You’re just trading in one set of challenges and difficulties for another.

This brings me to the biggest lesson of our ProjectFlow experience. It’s about understanding who we are, what we want to achieve, and how we go about achieving them. Chasing the dream of becoming the next Basecamp while still deeply entrenched in client work proved to be difficult and perhaps retarded our growth as a provider of client services. We’ve given ourselves enough exposure to the grass on the SaaS product side of the pasture to understand that it’s not always so green. Customer acquisition costs, constant feature requests, the threat of unfavorable reviews and tweets, churn rates, the monotony of working on the same code base, endless customer support emails, and the glut of competition: these are things I’ve seen firsthand in working on ProjectFlow. Running a SaaS product business is just as much hard work as client services. You’re just trading in one set of challenges and difficulties for another. I’m grateful to have had the opportunity to explore a different type of business and to have picked up many valuable lessons. As we move forward, we find ourselves focused and motivated to become the best client services company that we can be.

Resources/Tools That We Found Helpful

Intercom
Really great tool for SaaS products for tracking user engagement and managing communications with customers. We used Intercom to see that, for example, with over 10,000 sign-ups, there were actually just 800 or so users who were active (logged in recently, logged in more than a few times, and created new things on the board). We also used Intercom to track if people made changes to the board title or to see how many columns they added, which gave us helpful data in making design decisions. Their blog Inside Intercom also has some really great advice and ideas for people building SaaS products.

Invision
Wonderful prototyping tool that we use for almost all our client projects and also used for ProjectFlow. We mocked up new features and mapped out the user flows visually before getting Kevin to code them. Discussions around user experience were much easier using Invision.

YouEye
We used YouEye to do some user testing prior to launching ProjectFlow. YouEye provides user testing services and records the reactions of the users. Being able to observe people interacting with ProjectFlow gave us some critical insights and allowed us to make very important user interface adjustments that would eliminate confusion. One thing you’ll notice about ProjectFlow is that we don’t have any help guides when you first log in. We felt that our tool was intuitive enough and that the testing confirmed (along with subsequent feedback from users) that we could do without pop-up modals for first-time users.