aka: Screw you Joel Spolsky, We're Rewriting It From Scratch!
This is a guest post by Dan Milstein (@danmil), co-founder of Hut 8 Labs.
Disclosure: Joel Spolsky is a friend and I'm an investor in his company, Stack Exchange (which powers the awesome Stack Overflow) -Dharmesh
So, you know Joel Spolsky's essay Things You Should Never Do, Part I? In which he urgently recommends that, no matter what, please god listen to me, don't rewrite your product from scratch? And lists a bunch of dramatic failures when companies have tried to do so?
First off, he's totally right. Developers tend to spectacularly underestimate the effort involved in such a rewrite (more on that below), and spectacularly overestimate the value generated (more on that below, as well).
But sometimes, on certain rare occasions, you're going to be justified in rewriting a major part of your product (you'll notice I've shifted to saying you're merely rewriting a part, instead of the whole product. Please do that. If you really are committed to just rewriting the entire thing from scratch, I don't know what to tell you).
If you're considering launching a major rewrite, or find yourself as the tech lead on such a project in flight, or are merely toiling in the trenches of such a project, hoping against hope that it will someday end... this post is for you.
Hello, My Name is Dan, and I've Done Some Rewrites
A few years back, I joined a rapidly growing startup named HubSpot, where I ended up working for a good solid while (which was a marvelous experience, btw -- you should all have Yoav Shapira as a boss at some point). In my first year there, I was one of the tech leads on a small team that rewrote the Marketing Analytics system (one of the key features of the HubSpot product), totally from scratch. We rewrote the back end (moving from storing raw hit data in SQLServer to processing hits with Hadoop and storing aggregate reports in MySQL); we rewrote the front end (moving from C#/ASP.Net to Java/Tomcat); we got into the guts of a dozen applications which had come to rely on that store of every-hit-ever, and found a way to make them work with the data that was now available. (Note: HubSpot is now primarily powered by MySQL/Hadoop/HBase. Check out the HubSpot dev blog).
It took a loooong time. Much, much longer than we expected.
But it generated a ton of value for HubSpot. Very Important People were, ultimately, very happy about that project. After it wrapped up, 'Analytics 2.0', as it was known, somehow went from 'that project that was dragging on forever', to 'that major rewrite that worked out really well'.
Then, after the Analytics Rewrite wrapped up, in my role as 5 Whys Facilitator, I led the post-mortem on another ambitious rewrite which hadn't fared quite so well. I'll call it The Unhappy Rewrite.
From all that, some fairly clear lessons emerged.
First, I'm going to talk about why these projects are so tricky. Then I'll pass on some of those hard-won lessons on how to survive.
Prepare Yourself For This Project To Never Fucking End
The first, absolutely critical thing to understand about launching a major rewrite is that it's going to take insanely longer than you expect. Even when you try to discount for the usual developer optimism. Here's why:
- Migrating the data sucks beyond all belief
I'm assuming your existing system has a bunch of valuable data locked up in it (if it doesn't, congrats, but I just never, ever run into this situation). You think, we're going to set up a new db structure (or move it all to some NoSQL store, or whatever), and we'll, I dunno, write some scripts to copy the data over, no problem.
Problem 1: there's this endless series of weird crap encoded in the data in surprising ways. E.g. "The use_conf field is 1 if we should use the auto-generated configs... but only if the spec_version field is greater than 3. Oh, and for a few months, there was this bug, and use_conf was left blank. It's almost always safe to assume it should be 1 when it's blank. Except for customers who bought the Express product, then we should treat it as 2". You have to migrate all your data over, checksum the living hell out of it, display it back to your users, and then figure out why it's not what they expect. You end up poring over commit histories, email exchanges with developers who have long since left the company, and line after line of cryptic legacy code. (In prep for writing this, when I mentioned this problem to developers, every single time they cut me off to eagerly explain some specific, awful experience they've had on this front -- it's really that bad)
Problem 2: But, wait, it gets worse: because you have a lot of data, it often takes days to migrate it all. So, as you struggle to figure out each of the above weird, persnickety issues with converting the data over, you end up waiting for days to see if your fixes work. And then to find the next issue and start over again. I have vivid, painful memories of watching my friend Stephen (a prototypical Smart Young Engineer), who was a tech lead on the Unhappy Rewrite, working, like, hour 70 of an 80 hour week, babysitting a slow-moving data export/import as it failed over and over and over again. I really can't communicate how long this takes.
- It's brutally hard to reduce scope
With a greenfield (non-rewrite) project, there is always (always) a severe reduction in scope as you get closer to launch. You start off, expecting to do A, B, C & D, but when you launch, you do part of A. But, often, people are thrilled. (And, crucially, they forget that they had once considered all the other imagined features as absolutely necessary)
With a rewrite, that fails. People are really unhappy if you tell them: hey, we rewrote your favorite part of the product, the code is a lot cleaner now, but we took away half the functionality.
You'll end up spending this awful series of months implementing all these odd edge cases that you didn't realize even existed. And backfilling support for features that you've been told no one uses any more, but you find out at the last minute some Important Person or Customer does. And, and, and...
- There turn out to be these other system that use "your" data
You always think: oh, yeah, there are these four screens, I see how to serve those from the new system. But then it turns out that a half-dozen cron jobs read data directly from "your" db. And there's an initialization step for new customers where something is stored in that db and read back later. And some other screen makes a side call to obtain a count of your data. Etc, etc. Basically, you try turning off the old system briefly, and a flurry of bug reports show up on your desk, for features written a long time ago, by people who have left the company, but which customers still depend on. This takes forever all over again to fix.
Okay, I'm Sufficiently Scared Now, What Should I Do?
You you have to totally own the business value.
First off, before you start, you must define the business value of this rewrite. I mean, you should always understand the big picture value of what you do (see: Rands Test). But with rewrites, it's often the tech lead, or the developers in general, who are pushing for the rewrite -- and then it's absolutely critical that you understand the value. Because you're going to discover unexpected problems, and have to make compromises, and the whole thing is going to drag on forever. And if, at the end of all that, the Important People who sign your checks don't see much value, it's not going to be a happy day for you.
One thing: be very, very careful if the primary business value is some (possibly disguised) version of "The new system will be much easier for developers to work on." I'm not saying that's not a nice bit of value, but if that's your only or main value... you're going to be trying to explain to your CEO in six months why nothing seems to have gotten done in development in the last half year.
The key to fixing the "developers will cry less" thing is to identify, specifically, what the current, crappy system is holding you back from doing. E.g. are you not able to pass a security audit? Does the website routinely fall over in a way that customers notice? Is there some sexy new feature you just can't add because the system is too hard to work with? Identifying that kind of specific problem both means you're talking about something observable by the rest of the business, and also that you're in a position to make smart tradeoffs when things blow up (as they will).
As an example, for our big Analytics rewrite, the developers involved sat down with Dan Dunn, the (truly excellent) product guy on our team, and worked out a list of business-visible wins we hoped to achieve. In rough priority order, those were:
Cut cost of storing each hit by an order of magnitude
Create new reports that weren't possible in the old system
Serve all reports faster
Serve near-real-time (instead of cached daily) reports
And you should know: that first one loomed really, really large. HubSpot was growing very quickly, and storing all that hit data as individual rows in SQLServer had all sorts of extra costs. The experts on Windows ops were constantly trying to get new SQLServer clusters set up ahead of demand (which was risky and complex and ended up touching a lot of the rest of the codebase). Sales people were told to not sell to prospects with really high traffic, because if they installed our tracking code, it might knock over those key databases (and that restriction injected friction into the sales process). Etc, etc.
Solving the "no more hits in SQLServer" problem is the Hard kind for a rewrite -- you only get the value when every single trace of the old system is gone. The other ones, lower down the list, those you'd see some value as individual reports were moved over. That's a crucial distinction to understand. If at all possible, you want to make sure that you're not only solving that kind of Hard Problem -- find some wins on the way.
For the Unhappy Rewrite, the biz value wasn't perfectly clear. And, thus, as often happens in that case, everyone assumed that, in the bright, shiny world of the New System, all their own personal pet peeves would be addressed. The new system would be faster! It would scale better! The front end would be beautiful and clever and new! It would bring our customers coffee in bed and read them the paper.
As the developers involved slogged through all the unexpected issues which arose, and had to keep pushing out their release date, they gradually realized how disappointed everyone was going to be when they saw the actual results (because all the awesome, dreamed-of stuff had gotten thrown overboard to try to get the damn thing out the door). This a crappy, crappy place to be -- stressed because people are hounding you to get something long-overdue finished, and equally stressed because you know that thing is a mess.
Okay, so how do you avoid getting trapped in this particular hell?
Worship at the Altar of Incrementalism
Over my career, I've come to place a really strong value on figuring out how to break big changes into small, safe, value-generating pieces. It's a sort of meta-design -- designing the process of gradual, safe change.
Kent Beck calls this Succession, and describes it as:
"Design changes are usually most efficiently implemented as a series of safe steps. Succession is the art of taking a single conceptual change, breaking it into safe steps, and then finding an order for those steps that optimizes safety, feedback, and efficiency."
I love that he calls it an "art" -- that feels exactly right to me. It doesn't happen by accident. You have to consciously work at it, talk out alternatives with your team, get some sort of product owner or manager involved to make sure the early value you're surfacing matters to customers. It's a creative act.
And now, let me say, in an angry Old Testament prophet voice: Beware the false incrementalism!
False incrementalism is breaking a large change up into a set of small steps, but where none of those steps generate any value on their own. E.g. you first write an entire new back end (but don't hook it up to anything), and then write an entire new front end (but don't launch it, because the back end doesn't have the legacy data yet), and then migrate all the legacy data. It's only after all of those steps are finished that you have anything of any value at all.
Fortunately, there's a very simple test to determine if you're falling prey to the False Incrementalism: if after each increment, an Important Person were to ask your team to drop the project right at that moment, would the business have seen some value? That is the gold standard.
Going back to my running example: our existing analytics system supported a few thousand customers, and served something like a half dozen key reports. We made an early decision to: a) rewrite all the existing reports before writing new ones, and b) rewrite each report completely, push it through to production, migrate any existing data for that report, and switch all our customers over. And only then move on to the next report.
Here's how that completely saved us: 3 months into a rewrite which we had estimated would take 3-5 months, we had completely converted a single report. Because we had focused on getting all the way through to production, and on migrating all the old data, we had been forced to face up to how complex the overall process was going to be. We sat down, and produced a new estimate: it would take more like 8 months to finish everything up, and get fully off SQLServer.
At this point, Dan Dunn, who is a Truly Excellent Product Guy because he is unafraid to face a hard tradeoff, said, "I'd like to shift our priorities -- I want to build the Sexy New Reports now, and not wait until we're fully off SQLServer." We said, "Even if it makes the overall rewrite take longer, and we won't get off SQLServer this year, and we'll have to build that one new cluster we were hoping to avoid having to set up?" And he said "Yes." And we said, "Okay, then."
That's the kind of choice you want to offer the rest of your larger team. An economic tradeoff where they can chose between options of what they see when. You really, really don't want to say: we don't have anything yet, we're not sure when we will, your only choices are to keep waiting, or to cancel this project and kiss your sunk costs goodbye.
Side note: Dan made 100% the right call (see: Excellent). The Sexy New Reports were a huge, runaway hit. Getting them out sooner than later made a big economic impact on the business. Which was good, because the project dragged on past the one year mark before we could finally kill off SQLServer and fully retire the old system.
For you product dev flow geeks out there, one interesting piece of value we generated early was simply a better understanding of how long the project was going to take. I believe that is what Beck means by "feedback". It's real value to the business. If we hadn't pushed a single report all the way through, we would likely have had, 3-4 months in, a whole bunch of data (for all reports) in some partially built new system, and no better understanding of the full challenge of cutting even one report over. You can see the value the feedback gave us--it let Dan make a much better economic choice. I will make my once-per-blog-post pitch that you should go read Donald Reinertsen's Principles of Product Development Flow to learn more about how reducing uncertainty generates value for a business.
For the Unhappy Rewrite, they didn't work out a careful plan for this kind of incremental delivery. Some Totally Awesome Things would happen/be possible when they finished. But they kept on not finishing, and not finishing, and then discovering more ways that the various pieces they were building didn't quite fit together. In the Post-Mortem, someone summarized it as: "We somehow turned this into a Waterfall project, without ever meaning to."
But, I Have to Cut Over All at Once, Because the Data is Always Changing
One of the reasons people bail on incrementalism is that they realize that, to make it work, there's going to be an extended period where every update to a piece of data has to go to both systems (old and new). And that's going to be a major pain in the ass to engineer. People will think (and even say out loud), "We can't do that, it'll add a month to the project to insert a dual-write layer. It wil slow us down too much."
Here's what I'm going to say: always insert that dual-write layer. Always. It's a minor, generally somewhat fixed cost that buys you an incredible amount of insurance. It allows you, as we did above, to gradually switch over from one system to another. It allows you to back out at any time if you discover major problems with the way the data was migrated (which you will, over and over again). It means your migration of data can take a week, and that's not a problem, because you don't have to freeze writes to both systems during that time. And, as a bonus, it surfaces a bunch of those weird situations where "other" systems are writing directly to your old database.
Again, I'll quote Kent Beck, writing about how they do this at Facebook:
"We frequently migrate large amounts of data from one data store to another, to improve performance or reliability. These migrations are an example of succession, because there is no safe way to wave a wand and migrate the data in an instant. The succession we use is:
Convert data fetching and mutating to a DataType, an abstraction that hides where the data is stored.
Modify the DataType to begin writing the data to the new store as well as the old store.
Bulk migrate existing data.
Modify the DataType to read from both stores, checking that the same data is fetched and logging any differences.
When the results match closely enough, return data from the new store and eliminate the old store.
You could theoretically do this faster as a single step, but it would never work. There is just too much hidden coupling in our system. Something would go wrong with one of the steps, leading to a potentially disastrous situation of lost or corrupted data."
Abandoning the Project Should Always Be on the Table
If a 3-month rewrite is economically rational, but a 13-month one is a giant loss, you'll generate a lot value by realizing which of those two you're actually facing. Unfortunately, the longer you solider on, the harder it is for people to avoid the Fallacy of Sunk Costs. The solution: if you have any uncertainty about how long it's going to take, sequence your work to reduce that uncertainty right away, and give people some "finished" thing that will let them walk away. One month in, you can still say: we've decided to only rewrite the front end. Or: we're just going to insert an API layer for now. Or, even: this turned out to be a bad idea, we're walking away. Six months in, with no end in sight, that's incredibly hard to do (even if it's still the right choice, economically).
Some Specific Tactics
Shrink Ray FTW
This is an excellent idea, courtesy of Kellan Elliot-McCrea, CTO of Etsy. He describes it as follows:
"We have a pattern we call shrink ray. It's a graph of how much the old system is still in place. Most of these run as cron jobs that grep the codebase for a key signature. Sometimes usage is from wire monitoring of a component. Sometimes there are leaderboards. There is always a party when it goes to zero. A big party.
Gives a good sense of progress and scope, especially as the project is rolling, and a good historical record of how long this shit takes. '''
I've just started using Shrink Ray on a rewrite I'm tackling right now, and I will say: it's fairly awesome. Not only does it give you the wins above, but, it also forces you to have an early discussion about what you are shrinking, and who in the business cares. If you make the right graph, Important People will be excited to see it moving down. This is crazy valuable.
Engineer The Living Hell Out Of Your Migration Scripts
It's very easy to think of the code that moves data from the old system to the new as a collection of one-off scripts. You write them quickly, don't comment them too carefully, don't write unit tests, etc. All of which are generally valid tradeoffs for code which you're only going to run once.
But, see above, you're going to run your migrations over and over to get them right. Plus, you're converting and summing up and copying over data, so you really, really want some unit tests to find any errors you can early on (because "data" is, to a first approximation, "a bunch of opaque numbers which don't mean anything to you, but which people will be super pissed off about if they're wrong"). And this thing is going to happen, where someone will accidentally hit ctrl-c, and kill your 36 hour migration at hour 34. Thus, taking the extra time to make the entire process strongly idempotent will pay off over and over (by strongly idempotent, I mean, e.g. you can restart after a failed partial run and it will pick up most of the existing work).
Basically, treat your migration code as a first class citizen. It will save you a lot of time in the long run.
If Your Data Doesn't Look Weird, You're Not Looking Hard Enough
What's best is if you can get yourself to think about the problem of building confidence in your data as a real, exciting engineering challenge. Put one of your very best devs to work attacking both the old and the new data, writing tools to analyze it all, discover interesting invariants and checksums.
A good rule of thumb for migrating and checksumming data: until you've found a half-dozen bizarre inconsistencies in the old data, you're not done. For the Analytics Rewrite, we created a page on our internal wiki called "Data Infelicities". It got to be really, really long.
With Great Incrementalism Comes Great Power
I want to wrap up by flipping this all around -- if you learn to approach your rewrites with this kind of ferocious, incremental discipline, you can tackle incredibly hard problems without fear. Which is a tremendous capability to offer your business. You can gradually rewrite that unbelievably horky system that the whole company depends on. You can move huge chunks of data to new data stores. You can pick up messy, half-functional open source projects and gradually build new products around them.
It's a great feeling.
What's your take? Care to share any lessons learned from an epic rewrite?
Article has 2
comments. Click To Read/Write Comments
Ben Yoskovitz is the co-author of Lean Analytics, a new book on how to use analytics successfully in your business. Ben is currently VP Product at GoInstant, which was acquired by Salesforce in 2012. He blogs regularly at Instigator Blog and can be followed @byosko.
We all know metrics are important. They help report progress and guide our decision making. Used properly, metrics can provide key insights into our businesses that make the difference between success and failure. But as our capacity to track everything increases, and the tools to do so become easier and more prevalent, the question remains: what is a worthwhile metric to track?
Before you can really figure that out it's important to understand the basics of metrics. There are in fact good numbers and bad numbers. There are numbers that don't help and numbers that might save the day.
First, here's how we define analytics: Analytics is the measurement of movement towards your business goals.
The two key concepts are "movement" and "business goals". Analytics isn't about reporting for the sake of reporting, it's about tracking progress. And not just aimless progress, but progress towards something you're trying to accomplish. If you don't know where you're going, metrics aren't going to be particularly helpful.
With that definition in mind, here's how we define a "good metric".
A good metric is:
A ratio or rate
A good metric is comparative. Being able to compare a metric across time periods, groups of users, or competitors helps you understand which way things are moving. For example, "Increased conversion by 10% from last week" is more meaningful than "We're at 2% conversion." Using comparative metrics speaks clearly to our definition of "movement towards business goals".
A good metric is understandable. Take the numbers you're tracking now--the ones you think are the most important--and show those to outsiders. If they don't instantly understand your business and what you're trying to do, then the numbers you're tracking are probably too complex. And internally, if people can't remember the numbers you're focused on and discuss them effectively, it becomes much harder to turn a change in the data into a change in the culture. Try fitting your key metrics on a single TV screen (and don’t cheat with a super small font either!)
A good metric is a ratio or a rate. Ratios and rates are inherently comparative. For example, if you compare a daily metric to the same metric over a month, you'll see whether you're looking at a sudden spike or a long-term trend. Ratios and rates (unlike absolute numbers) give you a more realistic "health check" for your business and as a result they're easier to act on. This speaks to our definition above about "business goals"--ratios and rates help you understand if you're heading towards those goals or away from them.
A good metric changes the way you behave. This is by far the most important criterion for a metric: what will you do differently based on changes in the number? If you don't know, it's a bad metric. This doesn't mean you don't track it--we generally suggest that you track everything but only focus on one thing at a time because you never know when a metric you're tracking becomes useful. But when looking at the key numbers you're focused on today, ask yourself if you really know what you'd do if those numbers go up, down or stay the same. If you don't, put those metrics aside and look for better ones to track right now.
Now that we've defined a "good" metric let's look at five things you should keep in mind when choosing the right metrics to track:
Qualitative versus quantitative metrics
Vanity versus actionable metrics
Exploratory versus reporting metrics
Leading versus lagging metrics
Correlated versus causal metrics
1. Qualitative versus Quantitative metrics
Quantitative data is easy to understand. It's the numbers we track and measure--for example, sports scores and movie ratings. As soon as something is ranked, counted, or put on a scale, it's quantified. Quantitative data is nice and scientific, and (assuming you do the math right) you can aggregate it, extrapolate it, and put it into a spreadsheet. Quantitative data doesn't lie, although it can certainly be misinterpreted. It's also not enough for starting a business. To start something, to genuinely find a problem worth solving, you need qualitative input.
Qualitative data is messy, subjective, and imprecise. It's the stuff of interviews and debates. It's hard to quantify. You can't measure qualitative data easily. If quantitative data answers "what" and "how much," qualitative data answers "why." Quantitative data abhors emotion; qualitative data marinates in it.
When you first get started with an idea, assuming you're following the core principles around Lean Startup, you'll be looking for qualitative data through problem interviews. You're speaking to people--specifically, to people you think are potential customers in the right target market. You're exploring. You're getting out of the building.
Collecting good qualitative data takes preparation. You need to ask specific questions without leading potential customers or skewing their answers. You have to avoid letting your enthusiasm and reality distortion rub off on your interview subjects. Unprepared interviews yield misleading or meaningless results. We cover how to interview people in Lean Analytics, but there have been many others that have done so as well. Ash Maurya’s book Running Lean provides a great, prescriptive approach to interviewing. I also recommend Laura Klein’s writing on the subject.
Sidebar: In writing Lean Analytics, we proposed the idea of scoring problem interviews. The basic concept is to take the qualitative data you collect during interviews and codify it enough to give you (hopefully!) new insight into the results. The goal of scoring problem interviews is to reduce your own bias and ensure a healthy dose of intellectual honesty in your efforts. Not everyone agrees with the approach, but I hope you'll take a look and try it out for yourself.
2. Vanity versus Actionable metrics
I won't spent a lot of time on vanity metrics, because I think most people reading OnStartups understand these. As mentioned above, if you have a piece of data that can't be acted upon (you don't know how movement in the metric will change your behavior) then it's a vanity metric and you should ignore it.
It is important to note that actionable metrics don't automatically hold the answers. They're not magic. They give you an indication that something fundamental and important is going on, and identify areas where you should focus, but they don't provide the answers. For example, if "percent of active users" drops, what do you do? Well, it's a good indication that something is wrong, but you'll have to dig further into your business to figure it out. Actionable metrics are often the starting point for this type of exploration and problem solving.
3. Exploratory versus Reporting metrics
Reporting metrics are straightforward--they report on what's going on in your startup. We think of these as "accounting metrics", for example, "How many widgets did we sell today?" Or, "Did the green or the red widget sell more?" Reporting metrics can be the results of experiments (and therefore actionable), but they don't necessarily lead to those "eureka!" moments that can change your business forever.
Exploratory metrics are those you go looking for. You're sifting through data looking for threads of information that are worth pursuing. You're exploring in order to generate ideas to experiment on. This fits what Steve Blank says a startup should spend its time doing: searching for a scalable, repeatable business model.
A great example of using exploratory metrics is from Mike Greenfield, co-founder of Circle of Moms. Originally, Circle of Moms was Circle of Friends (think: Google Circles inside Facebook). Circle of Friends grew very quickly in 2007-2008 to 10 million users, thanks in part to Facebook's open platform. But there was a problem--user engagement was terrible. Circle of Friends had great virality and tons of users, but not enough people were really using the product.
So Mike went digging.
And what Mike found was incredible. It turns out that moms, by every imaginable metric, were insanely engaged compared to everyone else. Their messages were longer, they invited more people, they attached more photos, and so on. So Mike and his team pivoted from Circle of Friends to Circle of Moms. They essentially abandoned millions of users to focus on a group of users that were actually engaged and getting value from their product. From the outside looking in this might have been surprising or confusing. You might find yourself at a decision point like Mike and worry about what investors will think, or other external influencers. But if you find a key insight in your data that’s incredibly compelling, you owe it to yourself to act on it, even if it looks crazy from the outside. For Mike and Circle of Moms, it was the right decision. The company grew their user base back up to 4 million users and eventually sold to Sugar Inc.
4. Leading versus Lagging metrics
Leading and lagging metrics are both useful, but they serve different purposes. Most startups start by measuring lagging metrics (or "lagging indicators") because they don't have enough data to do anything else. And that's OK. But it's important to recognize that a lagging metric is reporting the past; by the time you know what the number is, whatever you’re tracking has already happened. A great example of this is churn. Churn tells you what percentage of customers (or users) abandon your service over time. But once a customer has churned out they're not likely to come back. Measuring churn is important, and if it's too high, you'll absolutely want to address the issue and try to fix your leaky bucket, but it lags behind reality.
A leading metric on the other hand tries to predict the future. It gives you an indication of what is likely to happen, and as a result you can address a leading metric more quickly to try and change outcomes going forward. For example, customer complaints is often a leading indicator of churn. If customer complaints are going up, you can expect that customers will abandon and churn will also go up. But instead of responding to something that's already happened, you can dive into customer complaints immediately, figure out what's going on, resolve the issues and hopefully minimize the future impact in churn.
Ultimately, you need to decide whether the thing you're tracking helps you make better decisions sooner. Remember: a real metric has to be actionable. Lagging and leading metrics can both be actionable, but leading indicators show you what will happen, reducing your cycle time and making you leaner.
5. Correlated versus Causal metrics
A correlation is a seeming relationship between two metrics that change together, but are often changing as a result of something else. Take ice cream consumption and drowning. If you plotted these over a year, you'd see that they're correlated--they both go up and down at the same time. The more ice cream that's consumed, the more people drown. But no one would suggest that we reduce ice cream consumption as a way of preventing drowning deaths. That's because the numbers are correlated, and not causal. One isn't affecting the other. The factor that affects them both is actually the time of year--when it's summer, people eat more ice cream and they also drown more.
Finding a correlation between two metrics is a good thing. Correlations can help you predict what will happen. But finding the cause of something means you can change it. Usually, causations aren't simple one-to-one relationships--there’s lots of factors at play, but even a degree of causality is valuable.
You prove causality by finding a correlation, then running experiments where you control the other variables and measure the difference. It's hard to do, but causality is really an analytics superpower--it gives you the power to hack the future.
So what metrics are you tracking?
We’ve covered some fundamentals about analytics and picking good metrics. It's not the whole story (to learn more see our presentations and workshops on Lean Analytics), but I'd encourage you to take a look at what you're tracking and see if the numbers you care the most about meet the criteria defined in this post. Are the metrics ratios/rates? Are they actionable? Are you looking at leading or lagging metrics? Have you identified any correlations? Could you experiment your way to discovering causality?
And remember: analytics is about measuring progress towards goals. It's not about endless reports. It's not about numbers that go constantly "up and to the right" to impress the press, investors or anyone else. Good analytics is about speeding up and making better decisions, and developing key insights that become cornerstones of your startup.
Article has 0
comments. Click To Read/Write Comments
This is a guest post by Alex Turnbull. Alex is a serial SaaS entrepreneur and the CEO of Groove, a customer support software platform for startups and small businesses. Alex was previously a co-founder of Bantam Live, acquired by Constant Contact in 2011.
After many, many months of long hours, take-out and cheap beer, launch day is finally here.
Your eyes are sore from not having looked up from your computer in what seems like ages, and every part of your body is screaming at you to get some sleep, but you’re too hopped up on coffee and adrenaline to listen.
This is it. This is what we’ve been working our asses off for. To reveal ourselves to the world in all of our disruptive glory. Silicon Valley will kneel before us.
It’s like the slow, painstaking ride to the top of the first drop on a roller coaster; you just know it’s going to be absolutely exhilarating, but first you have to trudge all the way to the peak of a steep climb. Tired of waiting but itching with anticipation, you finally reach the top, and then…
Not a damn thing.
Scoble isn’t billing you as the next Instagram. You’re not showing up on Techmeme with a dozen stories about your launch. And the traffic. That sweet, traction-building traffic that you’ve been awaiting — the traffic that was going to prove that people were interested. That they wanted you. It never comes.
Who’s to blame for all of this?
That’s easy. TechCrunch. Those bastards.
If only they had read your press release, they would’ve seen that your story needs to be told! Your product is unique and compelling, dammit! How could they do this to you? How could they crush your dreams of a successful launch by totally ignoring your pitch?
Of course, you’re a startup. Bouncing back is in your DNA, and you get right back to work. But the experience is discouraging, and I've seen this story play out way too many times with friends and founders I’ve spoken to. And know that I’m speaking from experience: I've absolutely made this mistake before, too.
Here’s the reality: pitching TechCrunch is not a launch strategy.
It seems obvious, but it takes more than one hand for me to count the number of times a founder has told me that they expect their launch traction to come from getting picked up by TC (or Mashable, or VentureBeat, or AllThingsD, or any one of a number of similar outlets).
What every single hopeful founder with a similar plan doesn't realize (or doesn't take seriously enough) is that there are hundreds of other founders doing the exact same thing, and hitting the exact same “Tips” email account with their pitches.
Don’t get me wrong, here. Press is good, startup bloggers tell important stories and press outreach should be a part of your launch strategy. But it’s not enough.
So what’s a startup to do?
Let’s get this out of the way: a lot of folks will tell you that the first thing you should be focused on is building a great product that improves people’s lives. And they’re absolutely right. Nobody wants to hear about a crappy product, and more importantly, nobody wants to share your crappy product with their friends.
But let’s assume you've got something amazing. How do you get the world to notice?
First of all, shift your thinking. F*ck the world. It’s “tell everyone” approaches like this that lead to launch strategies like the one above. You don’t need the world to notice. You need highly qualified potential users to notice, and there’s a huge difference.
At Groove, we spent twelve months in beta, rigorously testing and iterating our HelpDesk and LiveChat apps to get them ready to launch.
But here’s something else we did, that you can do, too: we spent that time rabidly collecting email addresses of potential users. We asked our most engaged beta users to share our website (and lead collection portal) with their networks, we blogged about topics that were interesting to a customer support audience, and we wrote content for external outlets that brought value to readers, and loads of inbound leads to us.
When launch day came, we were ready: press release, pitch list, product video, blog post, email blast, the works. Here’s how it played out:
We pitched our press list.
The good people at TheNextWeb covered our beta launch a year ago, so they were interested in how far we've come. They wrote a great piece about us, and the inbound traffic got us about a few hundred signups. It was awesome.
Like everyone else, we also wanted to get Crunched. Or Mashed. Or Beaten.
But what hurt even more, is that like almost everyone else, we didn't get covered by any of them.
I have no doubt that a barrage of press coverage would've gotten us even more new users, but we knew that the odds were against us, so we planned for it.
Taking our carefully nurtured list of email addresses, we sent out an announcement about our launch, with clear calls to action to sign up and get in on the fun.
Double the signups, at nearly four times the conversion rate of visitors coming from the TNW piece.
Note that we didn't email this list cold: we had spent months giving away content for free, nurturing the relationships, before asking for anything. I can’t stress the importance of this enough.
We also sent an email out to beta users, announcing the launch and asking them to share Groove with friends who might find it useful. That email netted us another 120 users, at a conversion rate nearly double that of the TNW traffic.
It shouldn't be surprising that the most valuable traffic we got came from qualified leads we had already nurtured. But the problem is that most startups won’t make the effort to build that audience until after launch. I know, because as I've mentioned, I've made that mistake, too.
Look, I know that as an early-stage team, the chances that you have a full-time content person are nonexistent. But the chances that someone on your team has a modicum of writing chops are pretty damn good, and getting them to invest a couple of hours a week in this exercise can pay off in spades when the time comes.
At a loss for what to write about? Every startup should know how their customers think, and knowing what’s interesting to them is a major part of that, and it’s absolutely okay to ask them what they’d like to read about from you. Email them, survey them, chat with them. They'll appreciate it. Trust me.
In the meantime, here are a few ideas:
- Write about your startup experiences - be honest and transparent (check out Balsamiq-founder Peldi’s blog, where he captures this masterfully)
- Stir the pot. Share your thoughts on controversial topics with your audience.
- Offer best practices for your space.
- You’re probably an expert in whatever it is that you do — share your knowledge.
- Everyone likes a success story. Or one about failure. Tell yours.
- Show off case studies and interviews with your customers. This clues your audience in to what others using your product are doing well, and makes the featured customers feel good about themselves (and their relationship with your company).
Summary: Getting Crunched is not a launch strategy, and you shouldn't bet on it to make your startup blow up. Reach out to the press, but diversify your launch plan to reach qualified leads that you've already been nurturing. Invest in content. Profit. The end.
Article has 0
comments. Click To Read/Write Comments
We were convinced from the very beginning that strong PR would be the answer to our market entry prayers. This is the story of how our reality turned into something of the opposite effect.
The Familiar Doubt
Many friends, fellow founders and business professionals told us along the way that creating a B2B interactive business platform would be a difficult project. (Hey, we knew that.)
People later told us that the most difficult aspect would be market entry. (Again, no surprise there.) The consensus among those critical of our venture was consistent, and usually along the lines of, “Don’t you want to do something more glamorous than a B2B platform? Maybe something B2C?”
(Actually, we believe our concept is glamorous and quite frankly, exactly what we believe the B2B market calls for.)
Any way you thought about it, the task at hand was going to be tough. The start was the most challenging, with an idea and an empty platform. But we were not the first facing this issue; surely there would be ways to maneuver our way into our key markets?
We knew some companies who successfully bought profiles or created fake ones, but decided that if we really believed in our concept, we would need real people behind genuine profiles and articles. And that we would need press coverage.
How did we solve the first problem of filling the platform?
We first talked face-to-face with various professionals we knew to get them interested and excited enough to participate on the platform, even though the it was new. It was hard, but we did it. Twice. Once on the German site, and again, when we went international with the English platform.
We were ready to move onto the next stage.
How do you go about growing something like a self-publishing platform for B2B professionals? How do you create public awareness? Would press coverage do the trick? High-profile technology publications, with all of their reach, would be a nice start…wouldn’t they?
Indeed, we tried various forms of press outreach. After making a bad choice with a PR company for the German market, we chose the PR Company for our international venture with care. After months of consideration, research and negotiation, we made a deal with high hopes that we would see the benefits of this lucrative investment. While it would be wrong to say we gained nothing from this several month contract, it would be an exaggeration to say that it was worth the time, energy and money to do it again.
Maybe we chose the wrong firm or worked with people not experienced enough with an international, startup market. Regardless of the reason, we only barely inched along.
Eventually, we were forced to go out on our own to create brand awareness and ignite public interest.
The Big Guys
This time, we aimed for the big guys and landed one on our own. Coverage on GigaOM inspired positive feedback surrounding our concept and functionality. But as it turns out, getting highly coveted coverage is not enough. What happens is this: you get a spike of traffic, a couple of hundred or even thousands of visits for a day, but only a fraction of the traffic persists.
PR can work if you manage to stay continually on the radar of journalists. We did not succeed in getting enough “coverable” news out over and over again and thus faced the problem of limited exposure.
After personal and fired efforts, what did we learn?
Our PR still stank.
Without a celebrity investor or seven-figure financial round each month, we were forced to do what startups do best: build something from nothing, by using what we had.
Looking back, this hardship turned out to be a great thing for our business development. Without being able to rely on press coverage, we were forced to learn and engage in a marketing strategy - to find other ways to generate traffic and convert our target audience.
Essentially, our lukewarm PR made us better entrepreneurs.
How, exactly, did we manage to grow?
As a social publishing and content marketing platform we decided to do exactly what we had been advising our target group to do: run a content-based, social media campaign. The steps were as follows:
1. Research our target group: This involved getting to know the habits and motivations of our target group within each social media and online channel. It also required us to understand the conversations that were talking place about issues relevant to our service and knowing what our industry influencers were saying. Specific to our success, were analyzing Twitter and LinkedIn.
2. Connect with influencers: Connecting with influencers allowed us to learn the language of our industry and lay the foundation for future interaction. When we later began to produce content, we could guest post on these influencers’ blogs/websites and involve them in a series of interviews. In both cases, we found ways to expose ourselves to their followers.
3. Create content of utility: We knew that content had to be informative and engaging. Yet, the content that really made a difference for us was that which offered our platform and social media communities a sense of utility. If our content could be used to better understand the industry or tackle a common problem, it was more likely to be shared and discussed.
4. Publish content: This was when we had the opportunity to do what we had been advising our target group to do the whole time: publish on exploreB2B. Not only did we publish articles on our platform, we guest posted on active and relevant sites and blogs.
5. Distribute content: Publishing content was only one step of the battle. Distributing the totality of our content through our social communities served to create leads to our platform and, in turn, grow these subsidiary networks.
6. Continue to grow online communities: This was one of the largest factors in our spike in traffic and referrals. Once we grew our Twitter accounts and initiated daily interaction in LinkedIn groups, whole communities of like-minded people were exposed to – and became familiar with – our brand name. Growing our Twitter account from miniscule numbers to five-figure followers became a powerful increase in our visibility. Even though we are B2B, this kind of “social branding” played a large role in our growth.
Through a campaign of trial and error, we learned that social media and content marketing success is not immediate – and that it is not the result of one magical post. The persistence of our actions and the combination of the different measures resulted in a social media following, trust in our content, visibility, and stable platform growth.
What were our end results with PR?
1. A spike in traffic during April 2012.
Yes, that’s it. And it was smaller than our current (steady) growth rates.
What were our end results with content marketing?
1. Brand awareness.
2. Connection to key, industry influencers.
3. Large and active social media followings on more than one network.
4. Trust in our useful and engaging content.
5. An increase in weekly visits by a factor of ten.
6. An increase in registrations by a factor of ten.
In the few months we have spent content marketing, we have achieved something that gives much more value to our company than traffic spikes created by media coverage. We have an ongoing dialogue with our users, a network base that constantly returns to our site, and consistently grow our traffic.
Results from our content marketing campaign far outweigh any benefits we gained from being covered in the press.
We have survived by making ourselves the leaders of our own movement, utilizing the platform we created, employing the marketing strategy we recommend and connecting to thought leaders in our field.
Weekly traffic of exploreB2B from March 2012 to November 2012
Though our content marketing results were not instant, we were able to use this time to build trust and establish a reputation in “social business.”
With positive user feedback and a steady increase in their own article production, we now sense real stability in our social media and platform interactions.
At this point in time, our PR still sucks.
But, maybe that is just the point. It is due to the fact that our PR was not successful that we attained something that has proven more valuable in the end: steady, self-achieved, and sustainable growth.
The Fate of Your Brand
My advice for startup growth is to not rely on press to determine your market reputation. Instead, formulate a connection to your target group members by telling your own stories and sharing knowledge that defines your industry leadership. This provides a foundation for your own means of security and growth.
Using methods such as social media and content marketing, figure out where you can reach your target group and pursue them in helpful and entertaining ways. It’s not the tech journalists, bloggers and authors covering your competitors who protect and ensure the bottom line of your company.
In the end, it comes down to the people who trust you and find value in your ideas to decide the fate of your brand.
This was a guest post by Susanna Gebauer. She is one of the founders of the social publishing and content marketing platform, exploreB2B. You can also find Susanna on Twitter.
Article has 0
comments. Click To Read/Write Comments
The following is a guest post by Sravish Sridhar. Sravish is the Founder and CEO of Kinvey, a Backend as a Service platform that makes it easy for developers to setup and operate backends for mobile, tablet and web apps. He is a believer in mentor-backed entrepreneurship and you can follow Sravish on Twitter - @sravishsridhar.
I just finished reading Brad Feld’s new book, Startup Communities: Building an Entrepreneurial Ecosystem in your City. In it, Brad states that sustainable entrepreneurial communities must have:
- Active entrepreneurs who will be the leaders to drive the community forward,
- A long-term view and commitment to build the community,
- A continual set of activities that engage the entire entrepreneurial stack, and
- An inherent view of inclusiveness that ensures that anyone is welcome to participate -- not just entrepreneurs.
On a similar theme, Mark Suster, in a guest post in TechCrunch, adds that a successful startup community must also have a strong pool of tech founders, capital, well-attended events, great local universities, vocal champions, vibrant local press, etc.
Despite embodying all the traits that Brad and Mark have outlined, I’ve repeatedly seen Boston, my current hometown, suffer from the burden of constantly justifying itself to the world as a thriving startup community. I’ve concluded that there is one more essential ingredient Boston needs to be a successful startup community – Boston needs early adopter DNA, especially to try early-stage, Boston-built, startup products.
If we could successfully mutate the startup gene of the Boston startup community to introduce early adopter DNA, we would create a huge advantage for startups that are built here. Their launches will be “buzzier,” their products will get traction faster, and most importantly, the companies will enjoy informed feedback from key members of its own community. Feedback and buzz from early adoption is an invaluable asset for any startup, and we can give them that.
For Boston (or any startup community) to have early adopter DNA, it needs its startup leaders and the extended community that supports the ecosystem to do three things –
1. Be Curious: We need to collectively spend more time seeking out new startups and learning about their products. Follow key Boston startup community leaders on Twitter like Dharmesh Shah, Matt Lauzon, Katie Rae, Jennifer Lum, David Cancel, Fred Destin, Rich Miner, Antonio Rodriguez, Rob Go, David Skok, Jeff Bussgang, etc. Read Scott Kirsner in the Boston Globe, BostInno, Xconomy and the Boston Business Journal. Learn, learn and learn!
I could go on and on. In Cambridge alone, there are hundreds of startups in a one-mile radius. And Boston has hundreds more. Ask yourself, how many of their products have you used?
2. Be Adventurous: When you read or hear about a new Boston startup, don’t hesitate - sign up and try its product. There are startups in Boston that cater to your every need -
3. Be Talkative: Trying a startup’s product is only the beginning. To truly become a vibrant entrepreneurial scene, we also need to support fellow startups with word of mouth. Tell your friends about your favorite local products, tweet and share your experience on Facebook. Better yet, blog about it.
Help your following become Curious and Adventurous. And don’t forget to share your product feedback with the startups behind the product. I can assure you that every startup wants to hear about your experience with their product, it’s how we will improve.
If we seek out innovation, are willing to kick the tires of early stage products, and be vocal about our experiences, Boston will become a stronger startup community. The ripples from this early adopter DNA being put into practice will encourage more people from the broader community to do the same, and I assure you, we will all be stronger for it.
Article has 1
comments. Click To Read/Write Comments
The following is a guest post by Iris Shoor. She's a co-founder at Takipi, a new startup looking to change the way developers work in the cloud. Previously, she was co-founder at VisualTao, a B2B startup acquired by Autodesk.
Call them hackers, ‘ninjas’, or ‘rock stars’ if you’d like. Other than being very talented developers, they all share one thing in common -- it’s unbelievably hard to bring them on-board your company. And as if competing with other companies for the same talent was not enough, being a startup just adds more challenges to the equation. Your startup may be the next Google/Facebook/Instagram, but until then - how can you convince the best developers out there to join a company where the CEO’s office is an IKEA desk? Here’s one answer -- recruit like a startup, in a creative and agile way, doing things the way big companies can’t. During the last 5 years I’ve interviewed over 250 candidates and recruited dozens of great engineers. The first interviews took place in our tiny office’s kitchen, and we still managed to convince some of the best candidates to join. There aren’t any magic tricks involved, but here are some tips and methods which helped us get ninjas, rock stars and other highly talented people on-board.
You’re a startup -- have the founders make the first contact.
We lose many potential candidates even before the starting line - we fail to bring them over for a first interview. Some are already talking with too many companies, or decide after a brief visit to your web-site that your startup just isn’t their thing. That’s the point where you can make a difference. Our co-founders (including myself) are in charge of sending the first e-mail to potential candidates. We’ve kept this habit even as we’ve grown. At first, I was worried some candidates may think we have too much free time on our hands (sadly, we don’t). I soon found out that when candidates receive a personal and flattering e-mail (important when it comes to star developers) from a co-founder, it sends a message that this startup is all about its employees. Here are some helpful points for writing the first email:
- Link to your online profile (personal blog, an interview with you, a YouTube video) when introducing yourself. Once there’s a face behind the email you’re more likely to get a positive response.
- Add a personal touch. Have other employees who went to the same college? Mention it. Grew up in the same town? Write it down. It might sound irrelevant, but it creates the first hook, enough to have them come over for a meeting.
Interviewing: It’s not just about the role, it’s also about who they will have lunch with.
While we tend to tell candidates everything about the role, the managers and the company, there’s one part that’s usually missing - who will they work with? One of the most common answers I get when asking people why they've chosen one job over the other is knowing other employees there. Let candidates know who'll be sitting next to their (IKEA) desk and sharing their 9GAG jokes.
- When candidates come for an interview we try to have them meet at least one future co-worker. A candidate asks a good tech question during the interview? Refer him to the engineer working on it instead of answering yourself. Found out the candidate has something in common with one of the employees (skydiving, growing up in Ohio, have a thing for ASCII art)? Introduce them. It’s not something we plan ahead, but given the opportunity, having the candidate stay at the office after the interview chatting with other employees, is considered a success.
- Don’t interview too early or too late during the day, when the office is empty. If the only time your future star can come in for an interview is 8:00am, make sure some people come early. You want to paint a full picture of what it will be like working at your startup.
[You don’t need a fancy office to make good impression - the small details do the job. Our entrance door has code on it and these are our meeting room custom coasters ]
Interviewing: Choose carefully which opportunity to pitch.
There truly are great things about joining a startup - new technological challenges, opportunities for moving up the ladder more quickly, learning about the business side of things, stock options and more. Don’t sell them all at once. Pitching becoming a manager to an engineer who just wants to experiment with new technologies? Bzzzz -- wrong move -- which might send her elsewhere.
- Look back - When we first started interviewing we used to ask candidates what they’re looking for. Instead of sharing their true motivations, they answered with what they thought was the ‘right’ answer -- “I just want to work on interesting stuff”. After a while we discovered the magic trick; instead of asking what they’re looking for now, we began asking how they've made previous job decisions. When asked about past decisions, people tend to share what really matters to them.
- Don’t pitch, give examples - You can’t really promise someone that he or she will become a manager in the future, or only work on interesting stuff. Instead, I tell candidates what talented people who've joined the company a year ago are doing now. This could be how an engineer with no previous management experience is already heading a small team, or how a developer straight out of college is doing such a great job we’ve put her in charge of some very key algorithms.
Signing: How to make candidates sign an employment agreement more quickly.
You've reached the homestretch. The candidate you really liked said yes, and now all is left is to sign the employment agreement. This can turn into a very risky period. The current employer is likely to come with a counter offer and so can other companies.
- Important: Avoid having your future star waste time on legal issues. To help with this we've decided to have the exact same employment agreement for everyone in the company. Other than the terms themselves, everything is the same - from the number of vacation days down to the small letters. It’s a super friendly agreement and we never change it. Once I tell candidates that everyone -- the CEO, the engineers and myself have all signed the exact same contract, and therefore we can’t change it, it usually takes them only a day or two to sign it. There’s much less need to re-read every part.
- Scott Weiss from A16Z shares a great tip about the pre-signing period with the ‘Welcome basket’.
How to hear ‘No” and how to say ‘No’
- Hearing No - Stay in touch with good candidates who chose a different company over yours. When a candidate I really like accepts a different offer over ours I always get the feeling I was dumped. True, I can’t honestly say I don’t understand how can someone pick a great job at Google over a small and unknown startup, but it still hurts. While the easiest thing to do after hearing a ‘No’ is, well, nothing, I try to make one last effort to stay in the picture. There are two main reasons for it : 1). Startups grow quickly. You might have a good candidate who decided a 10 employee company is not for him/her but a year or two later as your company grows it will become much more attractive. 2). Receiving a negative answer usually means you've reached second place. Sometimes, the first choice doesn't turn out to be the dream job they were hoping for. Some candidates don’t feel comfortable getting back in touch after they gave you a negative answer. By making the first move you’re saying that everything is fine and we’re still interested in you. Yes, it’s very much like dating. How to keep yourself in the picture? I like to send FB friend requests to candidates, and that’s something that you can do only as a startup (it can get pretty awkward when done by someone from a large company). Facebook is a great platform to share how well your startup is doing over the years. I also like sending an email once every 4-6 months, sharing how we’re doing and asking how’s everything going. I found out that most people find it friendly (and somehow flattering) rather than annoying.
- Saying No - giving a smart negative answer will help you reach other great engineers in the future. I often ask myself how I would have liked to receive a “No”. My answer is that I would like to hear the truth. Instead of using the default answer of “we've decided to continue the process with someone else”, I write the (sometime hard) truth- “You didn't pass the technical test’, ‘you don’t seem like a startup kind of guy’, ‘it seems like you’re more interested in managing and that’s something we can’t offer right now’. I also make sure to write some of the things I liked about the candidate. True, there are some cases you can’t write the real reason, but in most cases you can. I was terrified when I sent the first 100% sincere email, but I soon found out that candidates embrace this, and usually agree with the reason. Now comes the interesting part - instead of feeling rejected, most people rightly feel they interviewed for the wrong role. Once you don’t ‘break-up’ with them, you can ask them to recommend friends or co-workers they think could fit the position. Yep, it sounds crazy, but it’s true. Even if you don’t get a new lead, rest assured you’ll have a past candidate saying good things about your company, and that’s something great in itself.
How about you? Any lessons you've learned while trying to hire great developers for your team? Would love to hear your thoughts in the comments.
Article has 14
comments. Click To Read/Write Comments
The following is a guest post written bySanket Nadhani. He previously headed Marketing and Sales at FusionCharts and just launched an eBook on the complete journey of the company on its tenth birthday.
FusionCharts was founded in 2002 by my brother, Pallav Nadhani, in a quest for more pocket money. The charts people used on the web those days were Excel-type charts that were a pain to use, sat heavy on the servers often sending them crashing and burning, and generated deathly-dull output at the end of it all. FusionCharts came in with sexy, animated and interactive charts that were a breeze to use and installed the copy-paste way. Today, it has 20,000 customers and 450,000 users in 118 countries, powers more than a billion charts per month and clocks $7M in annual revenues. But that's not the interesting part. The interesting part is that this is the handiwork of a 17-year old with no business knowledge whatsoever living in India — a land that was nowhere on the product map a decade ago. In this post, I will share the unconventional problems that came our way and the lessons we learnt. Even though I moved on from FusionCharts a year back, I am still going to refer to it as "we" wherever required because that's how much a part of my identity it is. Also, brevity is good.
Wanting to make money is not a bad reason to start up
Ask any entrepreneur why they started up and the reasons would vary from “The project management tool we had didn't cut it for us to “The world of education had been languishing in the dark ages for too long.” And of course, there's that thing this Steve guy said that people love to repeat — I wanted to make a dent in the universe. But “I wanted to make money” is not something you hear of often. It sounds shallow, and most entrepreneurs shy away from it. FusionCharts started as a quest for more pocket money when as a teenager, Pallav needed more money to go bowling and hang out in cafes. Creating an interactive charting library isn't world-changing. It's not even sexy. But it solved his problem of making more pocket money.
It's not just about the product, it's the complete package
People don't want to know what a product can do, they want to know what a product can do for them
. So throwing a feature list in their face, no matter how nicely done, is not going to cut it. They need to have the this is it
feeling as soon as they hit your website. And more so, when you are sitting in India trying to sell to Fortune 500 companies around the world. Right from the early days, FusionCharts has had real-life business demos on its website. Sales dashboards, KPI monitors, network monitoring systems, and all of them with actual business data. Of course, we could have just put out the product with an extensive feature list and expected people to give us all their money. But instead we decided to put in hours conceptualizing the demos, gathering real-life data (dirty dirty job!) and then finally implementing them. But the end result was worth the effort. Project and product managers from large enterprises would come to the website with a picture of the dashboard they need in their head, see that we have a sales dashboard, click on it and go wow. This is exactly what I am looking for. They would then ask their development team to check it out and let them know if it was good to go. So what would otherwise take three phone calls and seven emails took all of five minutes of the manager's time, and no involvement from us at all.
Fighting fraud with freemium
Every time an organization is faced with a big problem, the kind that shifts the ground beneath their feet, they just start throwing resources at it. Big money, top people. But it doesn't have to be that way — big problems often have small inexpensive solutions. FusionCharts was commercially open source from day one. The idea behind making the source code available was that people would feel safe about buying from an unknown company from India. Even if FusionCharts turned out to be a fly-by-night operator or went down in crashing, burning flames for whatever reason, they could keep their charting up-to-date by building on the source code. However, this credibility-establishing factor almost spelt doom for FusionCharts. A company from Eastern Europe picked up the source code, made some small changes to it and started selling it as their own product for a cheaper price. Of course, they had to be sued. But going the legal way needed a lot of time and money, both of which FusionCharts didn't have at that point in time. So when a new version of FusionCharts was launched, the previous version was launched as FusionCharts Free. It was free to use in both personal and commercial projects, no strings attached. What the infringers were selling for slightly cheaper could be had from the original developers itself, for free. No one has tried pulling that trick ever again.
Marketing isn't just about money
The release of FusionCharts Free not only helped fend off the infringers, it also helped get the FusionCharts brand name out in markets that were tough to reach otherwise. Developers who are wary of playing with a trial version, believing it comes with some gimmick, got playing with the product and liked what they saw. Some developers built plugins and wrappers around FusionCharts Free for different platforms including GWT, Drupal and Joomla. Startups, who were low on money started using the free version in their product and when they had paying customers, they came back to get the paid version. In essence, FusionCharts Free has done more marketing for FusionCharts than even the best of traditional marketing campaigns.
If you have a picture of the US President using your product, tell the world about it
In 2009, the US national CIO unveiled the Federal IT Dashboard which was designed to give the public a look at the status of thousands of ongoing IT projects in the government. It also tracked the effectiveness of the government's overall IT spending — 600 billion dollars of them. The dashboard was using FusionCharts in plenty, something even Tim O'Reilly made a mention of in an article he wrote. That was a great story to go tell the world about, but it got even better. One of these nights, while idly browsing the web in the middle of the night, we came across a picture of Barack Obama using the Federal IT Dashboard. While we could have told the world how Barack Obama was using FusionCharts as a part of the Federal IT Dashboard, we decided to be bold and shortened it down to Barack Obama uses FusionCharts. And then we went to the mass media with the story. We were covered in many of the leading publications in the country. In fact till today, every coverage on FusionCharts makes a mention of Obama using FusionCharts in one way or the other. After all, how many companies can claim that White House uses their product with a picture to prove it?
Give people more reasons to remember you than just the product
Business isn't just about your product and offering. A large part of it is how people feel about you. A genuine conversation, a good story, they all add up. Every time we have gone to a tradeshow, we make a list of objectives which includes generating sales leads and getting press coverage. But another of those objectives, and a very important one, is to radiate warmth and happiness to every around. Even to people we spend only a minute with. And it reaps rich rewards when we come back to emails from people saying how much they enjoyed meeting us. There have been times when people have commented on a FusionCharts article somewhere on the web just to say that the team is very friendly. Words like those can brighten up even the toughest of days. And then of course, there's the power of a good story. People love stories, no matter how left-brained they are. So when FusionCharts completed a decade of being in business, we decided to write an eBook on the complete journey of the company, with warts and all. And the feedback we have got within a week of launching the book has been touching, to say the least. People who did business with us half a decade ago are writing in just reminiscing about the good old times. Entrepreneurs and aspiring entrepreneurs are writing in about how inspiring they found the story. Existing users and customers are writing in to say how they feel like a part of FusionCharts now. There's nothing like a good story.
A startup founded by a 17-year old in a country without a product ecosystem as such can never be smooth-sailing. But what it can be is extremely satisfying, as you tackle problems both usual and unusual. And extremely satisfying it has been. If you like what you read, check out the complete story of FusionCharts in Not Just Another Pie In The Sky.
What are some of the most unusual lessons you have learnt along your startup journey? Would love to hear your thoughts in the comments.
Article has 15
comments. Click To Read/Write Comments
The following is a guest blog post by Nicholas Holmes. Nicholas is the co-founder of MediaGraph, a public relations platform that enables small businesses to manage their own media outreach. He was formerly a journalist and an Accenture management consultant.
In my previous career as a journalist, I received hundreds of story pitches with press releases attached every day. Like so many other well-meaning journos, I'd make a valiant attempt to at least skim the first two lines of every one in a vain attempt to maintain some sort of equilibrium between the read and the unread.
In those two lines, I (and almost all the journalists I know) made a rapid judgement on the newsworthiness of content, never spending enough time thinking about what a story could become, rather than what it was. In short, if your piece of news wasn’t 100 percent right, it would rarely get the time of day.
Savvy PR practitioners know this. The best will be in contact all the time (or at least well before they have a news story to pitch) in an attempt to figure out how to maximize the chances of something being picked up. It’s a wonder there aren’t more of them. Sadly there aren’t and 80 - 90 percent of pitches I received followed the tired format of "Hi X, Company Y is launching a product next week and we thought it would be of interest to publication Z."
So here's an idea to try when getting media coverage for your startup - don't start by pitching the product. Start by pitching nothing.
Clearly showing that you understand that a journalist doesn't just exist to publicize you is one of the fastest routes to his or her heart. It’s literally the difference between drunkenly hitting on someone in a club and taking him/her on multiple dates to the restaurant you can’t afford. Hell, you'd be unlikely to start a sales pitch without knowing your customer, or begin discussions with an investor without finding out exactly what they were interested in -- so why treat the media differently?
The closest relationships journalists build are with people who can provide long-term value to them by offering something that isn't just self-promotion. Conversely, these tend to be the names you see cropping up again and again in the media.
So instead of a product pitch, why not offer something else if you’re trying to use the media to get the word out about your startup? The following list should get you started:
Having a network of people to offer opinion and analysis is critical for most journalists and it's a great way of getting your name out there, even when you don't have any news. So make sure your media contacts know who you are and what you're qualified to talk about by introducing yourself with a short biography and an offer to help.
Most journalism is about distilling complex topics into chunks that people understand, which means journalists need to be knowledgable about a lot, and always stay up-to-date. If you're an expert, or have access to experts, you can offer to spend some time highlighting trends or recent developments in your area to help journalists do their job better.
Perhaps it's a cliche, but one of the best ways to curry favor is to open doors. Does your business have an investor, a board member or a founder who's in demand? Offering an introduction to the right person can help ensure that you're remembered for the right reasons, and it doesn’t have to be just a cynical gesture. Connect two people who will benefit from knowing each other and you’ve done them both a good turn.
Many companies I've come across sit on piles of newsworthy data they've never considered using. It could be information interesting to everybody or just to a niche audience, but take a look at some other examples
of companies doing this and see if you might do something similar. Are you collecting data you can aggregate about your users that will be of interest to a consumer publication, such as their top tracks, movies or TV shows? Do you have access to collated information on Twitter that a journalist could use to prove a point? Or does your business measure something nobody else does?
Insights into the business
TechCrunch ran a surprisingly popular series (http://techcrunch.com/tag/tc-cribs/
) some years back which took a look around startup offices in the style of MTV Cribs -- a perhaps extreme example of how day-to-day business operations can be interesting. Think about whether your organization does anything particularly noteworthy operationally which could give a journalist some inspiration. Are there unique management styles or internal practices?
Too simple? Never! If you can meet conveniently, meeting a journalist face to face is the best way to make sure that you'll be remembered as more than just an email address. It also signals that you’re willing to invest serious time on getting to know this person, which will be appreciated - and who knows where you’ll both end up in the future?
Article has 11
comments. Click To Read/Write Comments
The following is a guest post from Dr. Jared Scherz, founder at UFeud, LLC, creators of ufeud.com, uframe, and uscore technologies.
As a well educated psychologist with a successful practice, the decision to launch a startup tech company tested the boundaries of my sense of self confidence and competence, as I was venturing into a field I knew little about. It was embarrassing to have to tell people on a somewhat regular basis that I didn't really know what I was doing. So how do I feel about that?' One day I'm plagued by self doubt and the next I'm feeling more confident because I figured something out. The excitement of a potentially lucrative new venture was tempered by the anxiety of self doubt and fear of the unknown. A destructive cycle of confidence and self doubt can develop as a result, and can wear out even the most resilient of people if not recognized so the pattern can change.
To help me climb out of this spin cycle is being able to identify and own my experience. Knowing what I'm feeling and how it influences my behavior or decision making is key to managing this dichotomy. This (internal) awareness helps reduce the chances of letting these unpleasant feelings translate into actions that require more energy and time to correct. If I know what I'm feeling and why, I can differentiate between what is my stuff and what is an organizational matter.
“I think I deserve more shares”: Let's use conflict with a co-founder as an example. The idea of a partner wanting to renegotiate their terms can be a major pitfall that sinks a startup, according to Noam Wasserman (The Founder's Dilemmas). This dilemma is common because we don't know well enough the contributions of each partner early in the project, and roles often change throughout the process. When a partner believes they are contributing more and their worth has increased, they may naturally want more equity and recognition.
Our initial response may be rigidity. Tensing up and digging in our heels, justifying our defensiveness as our partner's misdirected priorities. How dare they focus on greed as opposed to the company? Aren't they a team player? Why are they willing to sabotage everything we have been working toward? Then we ask ourselves the question, why does this feel like a betrayal? What's being evoked may be a loss of control or a feeling of fear that we are losing our grip on the company. Perhaps we lose trust in our partner, conjuring up all the times we have been let down by somebody in the past.
A startup is like a newly hatched chick, small and vulnerable to prey. Why can't I protect and control this entity I've worked so hard to create? After all, nobody was there at 3:00 am when I came up with the idea. (If they were, they probably could have shamed me out of that celebratory bowl of chocolate ice cream).
Paying attention to our experience will help us in a few different ways. We will have greater empathy towards our partner, allowing them to feel heard. Once your partner feels understood, they aren't going to put on a full court press to back you into a corner. Paying attention to our experience also allows us to separate past issues versus current ones. I'm aware that my partner is just nervous about all the extra work they are doing and they aren't like my ex-girlfriend who slept with my best friend in high school.
Expanding our self awareness helps with everyday interactions — not just the high intensity ones. Take a situation in which your programmers aren't following through on tasks with the alacrity they did when excitement in the project was higher. Aggravation can easily set in and snippiness can follow. We get on their case, which in turn causes resentment on their part and even slower responsiveness. Or, we can utilize our growing awareness and realize that we are being driven by fear.
In this scenario we add on a new level of awareness, which is external. Now instead of looking inward we are scanning our environment to pick up clues on what may be happening with others or even systems. In the example given above, our programmers may be feeling disconnected from the organization. They don't see all the effort going into marketing or how the sales team is getting positive feedback from the clients. All they hear is what isn't working and how they need to work faster. Their initial excitement has diminished and their frustration level is growing, hence their slowing response time. So getting on their case may work temporarily but in the long run it can create more chronic indifference.
Now that we have scanned our environment and determined that they are feeling detached and discouraged. We integrate this new information with our own heightened awareness and devise a more intentional response which serves both sides better.
Awareness is more complex then we realize it to be. It involves scanning both our internal and external environments to determine the impact we are having on others and others are having on us. Most situations that can be handled in a way that promotes cohesiveness on our teams can turn into disasters if we aren't using our awareness. A startup CEO with a high level of awareness will influence their organization in profound ways, most importantly helping the startup to become adaptive.
An adaptive organization as described by Eric Ries (The Lean Startup), is one in which the team uses data to learn and grow. Ries bases his concept on a validated learning approach that allows a company to measure their efforts and then pivot accordingly. What is also important in addition to learning from how our product is responded to, are the processes which exist among our team. Awareness is the key to understanding our own responses, the behaviors of our team, and the way in which different parts of the organization work together to form a whole.
Startups that don't prioritize adaptation are more prone to making mistakes and repeating these mistakes which can easily become maladaptive patterns. Getting excited after days of self-doubt and then making impulsive decisions without enough information is just the type of pattern that can be prevented with greater awareness. Adaptation is the direct result of scanning our environment and making changes based on the information obtained in a timely manner.
There are quite a few obstacles to improving one's awareness. The first is a CEO who is highly intelligent. Sound strange? Intelligent people tend to over-think and analyze. Awareness isn't about figuring things out with your mind; it's about using your body or more specifically your senses. Ask yourself what you feel in your gut, where you are holding tension, or what memories are being evoked.
Another obstacle is our resistance to giving up control. My startup is a product of a great idea, a tremendous amount of hard work and sacrifice, and we aren't about to see it decimated by apathy or greed. Remember that others may not feel the same passion as you do but they can be helped to take greater ownership if they know their feelings are valued. Taking time to scan others experience and verbalize what you imagine them to be feeling will go a long way toward building loyalty.
So take a moment and step back before reacting to people or situations. Ask yourself what is going on inside you to trigger your feelings. Consider what is driving the actions or inactions of others around you. Scan the team to see how people are working together and what the underlying causes are for problems. Base your responses on what emerges through your awareness to prevent impulsive decision making. As the CEO you are responsible for attending to the processes of your startup, not simply executing a wonderful product or service.
What do you think? Have you tried deliberately increasing your awareness — internal or external?
Article has 11
comments. Click To Read/Write Comments
The following is a guest post by Diana Urban. Diana is the Head of International Marketing at HubSpot, all-in-one marketing software
International expansion can provide a startup with tremendous growth opportunities. It allows your company to grow faster by casting a wider net, and helps diversify your revenue stream. While global expansion can be an exciting time, it’s a significant undertaking and requires some careful planning and making some hard decisions.
Today, HubSpot announced its European Headquarters launch in Dublin, Ireland. As part of the HubSpot International team, I wanted to share some of our learnings with you.
Here are six important things to consider when expanding a startup internationally:
1. Follow your customers and prospects
To determine where your biggest global opportunity exists, take a look at your customer base. If 50% of your International customer base is in Europe and only 8% is in Latin America, it makes a lot of sense to choose Europe as your International HQ. Let your domestic team build your Latin American segment up to a point where it’s ready for its own HQ. Make sure you have enough proven revenue in a region before opening up a new branch.
Also take a look at where the majority of your non-domestic prospects, or leads, live. You may notice that you’re generating the most leads in a country other than your largest international customer base. If this is the case, take conversion rates and cultural factors into consideration. Even though you’re generating a lot of leads in a particular country, can its population afford your products’ price point?
Finally, as much as we'd like to "follow the metrics" and make purely data-driven decisions, the choice of location might come down to people. Does one of the founders have a particular affinity or background in a location? Do you already have one of your stars anxious and eager to start an office in a particular country? These "people-based" factors should be considered. Often, the "optimal" decision from a metrics and revenue perspective is not the "best" decision.
2. Set ambitious international goals
Expanding internationally is a big investment, so it’s important to set ambitious goals to get the highest ROI possible. For example, plan for 30% of your business’ revenue to come from your global HQ within 3-5 years. Defining an international revenue goal for your international office will help you determine things like:
- How many sales reps do you need to generate $X in revenue?
- How many marketing leads do you need to generate to make those reps successful?
- How quickly does your international customer segment need to grow to reach that goal within 3 years?
- How many customer service reps will you need in order to serve this segment?
Whatever numbers you set to suit the needs of your own business, make sure you set those goals ahead of time so that you can plan accordingly every step of the way. Setting clear goals ahead of time will help keep the team that opens up the international headquarters accountable for its success.
3. Hire locally but be consistent culturally
A major benefit of opening up an office overseas is being able to recruit local talent, who will be experts in your industry in their culture. No matter how much you’ve been educated in the nuances of the culture you’re entering into, nobody will be better prepared than the people who grew up in the region.
If budget allows, try to bring over your new global employees for a couple weeks of training in your primary office. They will likely be teleconferencing frequently with your primary HQ, so having them join for training in-person helps put a face to the name for all future interactions.
Even though you should plan to hire mainly locals to staff your International Headquarters, be sure to maintain your company culture by sending over a group of expats, even if for a limited time range -- six to 12 months can suffice.
Most importantly, ensure that from Day 1, members of your international team feel like they're part of the company. Give them training. Give them career opportunities. Give them access to information and resources.
4. Network and attend conferences
Although America is becoming very dependent on virtual communication, in-person interaction is highly valued in cultures like Europe and East Asia. Use conferences and networking events to make connections with local industry-leaders in the region you’re opening your new office. Plan to stay a couple extra days after the conference for 1:1 meetings with your new connections. Meet with local press in-person to provide interviews on your global expansion plans.
Networking with the locals will help you spread the word not only about your product, but about the career opportunities now available to the local marketplace. You may need to hire aggressively your first couple years in your new office branch, so networking is imperative to drive high-quality candidates to your business.
5. Don’t underestimate cultural differences
Just as marketing best practices vary culture-to-culture, so do business practices. For example, in the U.S. it is typical for employees to have 10 non-holiday vacation days. However in Europe, it is customary for employees to have at least 20 non-holiday vacation days -- and be required to take all of them. It’s important to take this cultural difference into account when projecting sales quotas and development sprints.
6. Get support from finance, HR, and ops experts
When opening an office abroad, there are a lot of overhead elements to plan for, such as:
- Negotiating leases and contracts
- Determining company structure
- Setting up accounting and tax reporting systems
- Supporting expat and local employees’ HR needs
Expect that you will need ongoing support from your finance, HR, and operations departments, and plan to hire agencies to help if you don’t have the resources in-house. Again, global expansion is a big investment, and it’s important to get these basic elements right from the get-go.
Article has 11
comments. Click To Read/Write Comments