Doing Things that “Do Scale”

It can be fun doing things that don’t scale in the early days of a product or business. Whether it’s testing product-market fit, marketing messaging or innovation options, teams can be creative as they fine tune their business model. For example, InsightSquared, a Boston-based revenue analytics company, launched in 2010 to help customers understand distributed and complex data sets. The initial “product” was merely a collection of custom-built Excel sheets. It worked as customers realized value from the reports. Today, they solve the same problem, yet through a SaaS delivery model with integration into external business systems.

I first caught wind of the “do things that don’t scale” philosophy through Paul Graham’s groundbreaking essay on starting out. I have to admit, I love reading about the tactics employed by very successful companies in their early going. I often think about Dropbox who launched their product with only a video and sign-up form on a website. Today? Well, as I write this article, I’ll eventually save it to Dropbox and then sync with my account and other devices…. Amazing.

Assuming you test well, and serve a few customers well, you’ll be faced with a new challenge: Serve more of the market. If you’re like me, you’ve heard this challenge as a “good problem to have”. It is, but that doesn’t mean it’s an easy problem to solve.

My team and I were fortunate to be in this scenario recently. We had launched an MVP last fall and by mid-winter had witnessed ever-growing demand for the product. Great, right? It was time to play ball. Where we had previously enjoyed the liberties of crafting/executing our business plan on the fly, now we had to build a robust foundation. How could we effectively build, market, sell and support a product for the masses?

There’s a lot that goes into scaling a business, much more than I can cover in one article. But I wanted to share five strategies that helped us transition from a start-up product to a brand.

Nothing custom. In the launch stage, companies pivot as customers define the solution to a specific problem. In the scaling stage, much is defined: the solution, the messaging, the process, the fulfillment. Knowing we’d have to scale our resources behind this scaling effort, we aimed to shoot down variability. As a rule, we asked that Sales not deviate from the core product offering. Our thinking was that even the slightest, tiniest, easiest change would require additional effort that we might not be able to support. Without fail, custom deals always seem to require more effort than was originally surmised. While it was hard to turn down customers who required customization, we stayed disciplined and it helped our team focus.

Rationalize the roadmap. As a self-proclaimed “product guy”, I live for building new features and capabilities for our customers. So it killed me (and the rest of the team) when we had to wipe out half of the new stuff on our roadmap to make way for tech debt, performance fixes and bugs we didn’t yet know about. We committed to providing customers the highest quality product and built padding into the roadmap for improvements we didn’t yet know of, but were farely confident were coming.

The right people in the right places. In the startup stage, we had generalists, a small army wearing multiple hats. In growth mode, we assigned specialists. For instance, we put one of our most technical support folks as our lead technical implementation specialist. In launch mode, it was our lead engineer doing this job … on top of his day job. So for our team, it was about identifying where we needed folks, identifying who we needed to fill those roles and then defining roles and responsibilities across the board. By the way, folks changed roles and not everyone enjoyed his/her new role. We made difficult decisions, but for the right reasons.

Build a true feedback loop. For the first six months of our product’s life, I could list off our customers by name and had personally interacted with many. In scale mode, speaking with each individual customer wouldn’t be feasible. Yet, we didn’t want to forego valuable feedback. Foreseeing a growing customer base, we implemented not one but two feedback mechanisms. One was an in-product feedback form for customers. The other was a CRM-enabled feedback tracking system for Sales, Support. Through each we could seek out participants for deep-dive interviews and quantify feature requests. Lastly, we made sure to publish back where we were on specific requests, thus providing full transparency around the feedback and completing the loop.

Live the customer journey. The most important principle we employed was to not sully our brand, company and product. We understood that the customer experience would be stress tested with more leads flowing into the system and customers engaging with our offerings. We documented our customer journey thoroughly, pinpointing potential gaps where’d we bolster our processes with people and/or technology. We aimed for consistent messaging and were downright obsessed about role playing. We wanted to experience what customers would feel as they progressed through their buyer/customer journey. We did this for various scenarios and customer segments.

One byproduct of the customer journey exercise? It promoted cross-functional collaboration. Much like our customer base, our team was growing. Bringing folks together to solve big business challenges resulted in a different process, but a different type of fun.