Blog

ProjectFlow and the Hard-Learned Lessons from Building a Product

Tags:

September 04, 2013 by
ProjectFlow: Hard-Learned Lessons from Building a Product

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.

An earlier version of ProjectFlow on our touch screen.
That’s me using an earlier version of ProjectFlow on our touchscreen TV.

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
World map view of ProjectFlow users.
This vanity view of ProjectFlow users from Intercom shows users in 136 different countries.

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?

ProjectFlow Marketing Website
We updated our ProjectFlow marketing website in July 2013 to coincide with our paid features.

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.

  • moluv00

    Great write-up. The thing about hindsight is that it shows you all the reasons that you shouldn’t have taken action in the first place. Honestly, if you knew beforehand that this project should have a dedicated developer AND designer, and that it would cost $100K, would it ever have gotten past the drawing board? The only advice I’d offer is to keep the project going and to be VERY diligent about security. Nice work.

  • http://alexking.org Alex King

    Awesome write-up Peter. I think we all struggle to properly monitor and gauge the cost of our internal projects. Don’t even get me started about our own website redesign. :)

  • mccombs

    Fantastic write up. We’re a company who’s been client focused building websites and applications for clients for the past ~3 years and we’re just now facing some of the same challenges you mentioned with building our own SaaS product. I appreciate the honesty and transparency.

  • http://www.targetprocess.com/3 Michael Dubakov

    The only major mistake you made is poor functionality. ProjectFlow is similar to Trello, but loses to Trello in every possible way. I can’t find a single reason anyone will use ProjectFlow instead of Trello. If you have one, please share.

    There are tons of similar tools that do similar things and more. So you have to build something that differentiates ProjectFlow. As is, this service has no future for sure. Colorful columns is not a differentiator, it is a poor usability decision, since you lost an option to really color code important things.

    • Peter Kang

      Hey Michael, thanks for reading the article. You’re definitely right about us losing to Trello on many fronts. In fact, we’ve openly touted ProjectFlow as being similar to Trello but without much features. Our goal wasn’t to go head-to-head with a Trello but to create a very simple project tracking tool that would give you an at-a-glance idea. And we’ve really made the principle of less functionality core to ProjectFlow’s mission.

      We’ve had similar thoughts about the color columns as well (and explored perhaps a gradient option to help prioritize in-column), but we’ve received feedback from customers that the colors actually make the board really useful to visualizing the work/project load for certain phases. We’ll continue to explore ways we can add value by communicating with our customers.

      Btw, TargetProcess 3 looks really cool and a very polished product. We’ve been looking at some different Agile PM tools and it seems like you guys have a nice solution.

      • http://www.targetprocess.com/3 Michael Dubakov

        @disqus_gHiXJD1B0T:disqus I personally think it is not a viable business model to create a solution simpler than Trello. You can try to create a different solution, but Trello is quite simple. And Free. There is no way to win with simplification here.

        Thank you for the kind words about Targetprocess 3. It is not polished in fact and there are so many things to fix and improve.

  • floatschedule

    Good honest writing Peter. Props. – Glenn

  • http://neversettle.it/ Kenn

    Completely agree with this statement below and think many people see green grass and jump not knowing the weeds are the same on the other side. “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.”

  • http://www.strangerstudios.com Jason Coleman

    Great write-up. I’ve found it really useful to think about internal projects (in our case primarily the Paid Memberships Pro plugin) as if they were client work.

    First, if you are working at full capacity like we are, each hour spent on the internal project is one hour that we didn’t bill. The internal projects are costing us real money.

    Second, I often find myself delaying internal project milestones to work on client work. However, if I think about PMPro as a client project, they/us/we are our biggest client in terms of money/time spent and deserve to have timely releases, etc.

    FInally, if we had a client that we did hundreds of billable hours for and they never paid up (i.e. the internal project never generated revenue or enough revenue), we would fire that client. So it helps us to stay focused on making sure that time spent on the internal projects is really worth our time.

    We’re probably in a very similar boat, where I constantly second guess myself about giving up the opportunity to have a certain kind of lucrative services business in exchange for another business… or vice versa. In my case, the current business model for PMPro is for the product-level stuff to support itself and project while we build a services/consulting company on top of the product. I wonder at the same time if I’m giving up a lucrative product business while going after a services business… or if I’m just building two mediocre businesses instead of focusing on one option.

    Anyway, enough about me. Thanks for writing such a thoughtful and thought provoking article.

  • ElisaMillerOut

    Great blog post, Peter! I can really relate on all fronts. My service firm, Singlebrook, has also been working on developing a product business over the last year and a half and we’ve run into many of the same hurdles that you described. I really appreciate your honesty and transparency.

  • Pingback: ontario payday loans

  • Pingback: direct payday loans peterborough lender

  • Pingback: drugrehabcentershotline.com drug programs

Popular This Week
Taking Control of Image Loading
July 29, 2013

Taking Control of Image Loading

By Patrick Kunka
Text-align: Justify and RWD
March 12, 2013

Text-align: Justify and RWD

By Patrick Kunka
Wireframes the Barrel Way
July 03, 2013

Wireframes the Barrel Way

By Yvonne Weng
5 Blind Spots to Consider When Designing Web Apps
July 31, 2014

5 Blind Spots to Consider When Designing Web Apps

By Yvonne Weng

Like what you’re reading? Sign up for the Barrel newsletter and receive updates.