Category: startups

The Funnel is the Product, The Product is the Funnel

Others have made the important point that the critical word in the phrase “Software as a Service” (SaaS) is “Service” not “Software”.

Taking this a stage further, I believe that the traditional distinction between a company’s “Product” and the stuff that surrounds it needs to be completely eliminated.

In my view, this distinction is a hangover from the bygone days of software companies selling boxed software products.  In contrast, if you’re a SaaS company, you’re truly in the service business, not the software business, so your view of what constitutes your “product” has to evolve.

The Traditional View

The main building blocks of a “software company” have traditionally been:

  • the “Product” – this is the functionality that delivers on the company’s value proposition.  The “Product” is built by the development team and actively worked on.  For online software (i.e. most software these days), the “Product” is generally everything that’s behind the log-in stage.
  • “Marketing Material” – this is generally static content including the homepage and those other pages that are linked to from it.  It describes product features, benefits, case studies, etc.
  • “Sales” – unless your company relies solely on self-signups, these are people responsible for getting customers to pay for your product.  In contrast, the job of development is to create what people get after they’ve paid.  The Product does not directly help with “sales”, except in the obvious sense that it’s the promise made of what you’ll get when you pay and you might be allowed a free demo beforehand.
  • the “Funnel” – in most companies, there is typically the notion of a funnel – i.e. that series of steps that a person has to go through from first contact with your company to becoming a customer, be they on your website or on the phone with a sales rep. There may be people focused on increasing the conversion rate through your funnel (i.e. the % of people that end up being customers after first contact) and these people may even be active planning to reduce friction at each stage of the funnel.  However, the “Funnel” is generally still thought of as “marketing stuff” – not part of the “Product”.

What’s the Problem?

This is how the story of an Internet startup typically plays out:

After an initial launch, the rush is then on to keep evolving the product and keep delivering on a roadmap of features.  The development team thinks its job starts after the user is signed up and signed in and that its role is to give the user more and better stuff for their usage / money.

In contrast, the “marketing material” quickly becomes the poor step-child of the product and becomes stale as it increasingly gets out of sync with the product over time.

This happens for a few reasons:  partly because no one inside your company ever looks at it (out of sight, out of mind), partly because the marketing team is much smaller than the development team so there is little bandwidth for content changes and, often, because changing the static content is hard (it often requires involvement of developers who see it as busy work).

As for the Funnel; it may be actively measured by marketing and sales people. Also, noble efforts may be made to improve conversion each step along the way but the Funnel is still “marketing stuff” in the eyes of the development team and large scale changes to it are hard to make happen since the Funnel is not part of the “Product”.

Typically, the things that are deemed worthy of development attention and time are, in decreasing order:

#1 the platform
#2 the product
#3 the funnel
#4 the marketing material (static content)

Your Potential Customer’s View

Unfortunately, if you are in the shoes of a potential customer, it’s the marketing material you usually see first and which forms your first impression.

So, to the potential customer,  the order above is exactly the reverse order of importance.  It should be:

#1 the marketing material
#2 the funnel
#3 the product
(#4 the platform) – never really seen by the customer, except indirectly

You can lose huge numbers of potential customers on their first touch with your company if your marketing content is weak.  Inside your company, marketing and sales realize that first. Development often doesn’t realize it or does and doesn’t care.

This creates tension and all the required ingredients for a text-book “marketing versus development” internal feud seen in so many software companies.

The Funnel is the Product

The solution is to abandon the notion of “marketing stuff” vs “product”.

In this view, everything that a potential user sees is now your “product” and should be continually improved and finessed, starting from the stuff the potential user touches first – typically your homepage.  Because everything is now the “product”, development now owns it too.

For a lot of people, this is a pretty fundamental change so don’t expect to be able to make it over night.  It’s about seeing your product from an outside-in perspective, rather than an inside-out perspective.

However, this transition has a number of significant benefits:

  • everyone – including the development team – is engaged and feels responsible for driving usage and, if applicable to your business, sign-ups
  • much less, if any, “them versus us” mentality between marketing/sales and development
  • “marketing content” no longer the poor step-child and no longer out of date
  • the funnel is part of the product, usually resulting in a more innovative, more interactive and smoother funnel meaning less friction and, hence, more users

The Product Event Horizon

Making this change requires joined-up thinking.

As soon as someone has a slightest touch with your company, your product needs to act like a tractor-beam and gradually draw that person deeper and deeper in.  The product needs to progressively reveal more and more benefits and features and get the person to start using it without even realizing they are.

This is the “unconscious adoption of a product”.  Think of it as seducing your user.

At a certain point, the user crosses what I call the Product Event Horizon.  The Product Event Horizon is an invisible line that users hopefully won’t realize they’ve crossed but which they can never pass back across again.

(Read more about Event Horizons on Wikipedia if you want to know more about why I chose this term and geek-out on blackholes for a bit.)

Your company’s job is to push the Product Event Horizon out as close to possible to the first touch with your potential user and to make passing over it as unnoticeable as possible.  i.e. people start using your product without even realizing they are and before they can stop, they’re hooked.

To use a more plebeian analogy, the Pringles slogan had it right – “once you pop, you can’t stop”.

What to do

So, how do you actually make this change? Here are some pointers:

1.  Make sure everyone understands your funnel
Everyone in your company should understand the series of stages that a potential user goes through from first touch with your company to being an active user and/or paying customer.

More specifically, make sure everyone understands the conversion rate at each stage of the funnel – i.e. what people % of people advance to the next stage rather than drop off.

2.  Measure with tools
As the saying goes, you can’t manage what you can’t measure.  More specifically, you don’t know what changes help if you can’t measure their effects.

Another issue here is that SaaS companies are usually dominated by engineers and engineers generally hate “marketing stuff”.  They argue endlessly with sales and marketing over what’s important in the product.

However, engineers are generally suckers for facts and the scientific method.  If you show them actual data showing what users click on, how they make there way through the product from their first touch and where they drop off, there’ll be much less argument over what’s important to fix.

There are loads of tools out there but here are three of my favorites:

– CrazyEgg – click-tracking – presents a visual “heatmap” of where people click and what they scroll to
– Optimizely – predominantly an A-B testing tool but also tracks clicks
– Google Analytics – the obvious choice

3.  Make sure you can track users all the way through your product
An important step in the joined-up thinking and elimination of the distinction between “product” and “marketing stuff” is the ability to track a user all the way through from their first touch to their ongoing use of your product over time.  Don’t let data about conversion rates through your funnel stay separated or get separated from data about usage of your product.

4.  Get your head around and use Cohort Analysis
Cohort Analysis allows you to compare the behavior of your users based on how long they’ve been using your product rather than when they started using your product.  For example, it allows you to easily answer the question, “during their 2nd month of usage, how much did users who joined in January use the product versus those who joined in August?”

There are many articles out there on Cohort Analysis which explain what it is and why it’s important. Try starting here:

http://themetricsystem.rjmetrics.com/2009/09/09/cohort-analysis-in-rjmetrics/

5.  Invest in a Content Management System
A good Content Management System (CMS) will allow tweaks to the text, images, videos and, to some extent, layout, throughout your site without having to dive into raw HTML or source control.

This significantly decreases the time to make such changes and increases the number of people who are able to make them.  In turn, this means they can be tweaked much more frequently.

Importantly, don’t fall into the trap of only using a CMS for the “marketing stuff” and not for the “product”.  It should be easy to tweak language and layout throughout your whole site.

6.  A-B test as a matter of course
A-B testing is a habit you have to get into, rather like test-driven development.  A-B testing lets you answer the question scientifically as to whether a change you make has a positive benefit.

One note of caution is that A-B testing can only be effective once you have a certain volume of hits/users – you need enough volume in order for the comparison to be statistically significant. Premature A-B testing is a form of premature optimization that can hinder rather than help.  A-B test with too few hits/users and you’re trying to read tea-leaves, rather than apply the scientific method.
Fortunately, good A-B testing tools also let you know when you have enough data for the comparison to be statistically significant.

7.  Have a regular data meeting
This is the meeting where you review the data on how your company is performing.  It’s the meeting that engages everyone in driving the company by the numbers.

Ideally, have this meeting weekly.  In a small company, make it an all-hands meeting.  In bigger companies, make sure that there are representatives from all areas including, importantly, actual developers.  Make sure that no one can stick their head in the sand and get disconnected from the reality of your business.

Make it the most important meeting of the week.  It’s the heartbeat of your company.

The raw inputs are all that data you are collecting through the approaches above – funnel conversion rates, hits, click-tracking, A-B testing results, etc.

However, identify a small number – some say less than 10, others say only 1 – of metrics that you focus as the true indicators of how your business is doing.  You can dive into others as required.  Try to review too many data points and you can’t see the wood for the trees, the meeting drags on and people start to think of it as a chore.

8.  Hire a marketing engineer
Or, because these people are hard to find and are highly prized, convince someone internal to become your marketing engineer.

Marketing engineers bridge the gap between the marketing activities and software engineering – they live and breathe meta-data, tags, SEO, viral co-efficients and conversion rates.

On the face of it, developers should naturally gravitate towards this work since it’s hard, involves tinkering and is data-driven.  However, many developers still shy away from it because it smells of “marketing stuff”.

Agree, disagree?  Please leave a comment. (Hint: the link to comments is hidden at the top of the article, underneath the title.)

Why You Should (Almost) Never Rewrite Code – A Graphical Guide

I’m by no means the first person to write about the dangers of rewriting code.  The definitive work for me is “Things You Should Never Do, Part I” written by Joel Spolsky in 2000.  If you haven’t read that, you should.

A recent discussion caused me to create a series of charts to graphically illustrate the dangers of rewriting.  I tend to think graphically – blame too much time in Powerpoint creating VC pitch decks.

I hope these charts help anyone considering rewriting code or being hectored by earnest, bright, young engineers and architects advocating a rewrite.  I’ve seen this movie before and I know how it ends.

The Status Quo

Firstly, here’s the status quo:

The more time and money you spend on an existing product, generally speaking, the more functionality you get.

Let’s then overlay the competitiveness of the product in its target market.  Of course, what you want to achieve is a continual improvement in the competitiveness of the product.  Competitiveness doesn’t increase as fast as functionality.  Your competitors don’t stand still so, typically, the best you can hope for is to increase competitiveness gradually over time – even staying flat is a big challenge.

Of course, this chart is idealized – functionality will increase in a more lumpy way as you release major new chunks of functionality and competitiveness will move up and down against your market. However, they demonstrate the point.

Note:  the Y axis on all these charts represents “functionality” which, for the purposes of this discussion, can be considered a blend of features and quality.  The distinction between the two is not really important in this analysis since you always want to be advancing on one or both and they both impact overall product competitiveness.

Let’s Rewrite!

Cue your software architect.  He’s just been reading about this great new application framework and language called Ban.an.as – it’s so much better than the way you’ve been doing things previously. Hell, Ban.an.as has built-in back-hashed inline quadroople integration comprehensions. Plus, all the cool kids are using it.

If you’re a non-technical manager or executive, this can become quickly overwhelming and hard to argue against.  They’re the experts, right, so they must know what they’re talking about.

[By the way, if you’re a non-engineer, there’s no such thing as “back-hashed inline quadroople integration comprehensions” – I made that up.  Sorry.
A little secret here: there really haven’t been any new programming paradigms invented since the 1970s.  Software folks are generally in their 20s and didn’t see them the first time around – they just get “re-discovered” and given new names. Sssh – don’t tell anyone.]

Just to be clear – I’m not saying that new languages, frameworks and technologies can’t create significant improvements in developer productivity – they can.  But, their introduction into an existing product has a big price, as we’ll see.

Lastly, lest I alienate or offend my fellow geeks, I have been that very software architect advocating for the rewrite.  I learned this the hard way.

So, this is how the rewrite is supposed to work in theory:

Let’s break this down:

The rework is expected to take some amount of time.  During this time, functionality won’t increase because developers are focusing on rebuilding the foundations.
In the graph, that’s the blue area you can see peeking through.  That blue area represents the cost of the rewrite.

But, once the rewrite is done, the idea is that progress will be massively greater than it was previously because the new technology used is inherently better than the old.  Developers will be more productive with the new.  There’s no need to work with the old spaghetti code – instead, there’s a beautiful new architecture free of all the baggage that came before.

The critical point in time is the break-even point – this is the point at which the functionality of your product starts to exceed where you would have been had you stuck with the original implementation and continued working on it.

During the rewrite period, the competitiveness of your product will typically decline since your competitors are not standing still and you can’t develop new functionality.

However, the claim typically made by the rewrite advocates is that the rework will be relatively easy, take a relatively short period of time and hence achieve break-even quickly, after which it’s non-stop to the moon…

What tends to go wrong – Part 1

So, what tends to go wrong?  The most common problem is arguably the most common problem in software development generally; the rewrite takes significantly longer that expected.

There’s a discussion of why this tends to happen below but, for now, trust me that this often happens – if you’ve had any experience with software development at all, it’s highly likely that you’ve seen this happen too.

The result is that the cost of your rewrite is significantly larger than originally claimed.  (The blue area showing through on the chart is now much larger.)  This means that the break-even point is also significantly pushed back in time.

The knock-on effect is that the competitiveness of your product drops for a much longer period of time.

If you are a big company, you can probably (hopefully) absorb the pushed out break-even point – maybe other products provide revenue, maybe good channel relationships continue to deliver sales of your product even though it’s falling versus the competition or maybe you’ve simply got lots of cash reserves.  Joel Spolsky references several big company rewrites that failed but did not kill the company.

However, if you are a startup or smaller company (or even a less fortunate bigger company), this can be – some might argue, is very likely to be – fatal.

What tends to go wrong – Part 2

It gets worse.

Not only does the rewrite often take longer than expected but functionality is not even flat at the end of it – functionality is actually lost as a side-effect of the rewrite.

That’s because all of those small but important features, tweaks and bug-fixes that were in the original product don’t get reimplemented during the rewrite.  (These are the “hairs” that Joel discusses.)

Remember that the main focus of the rewrite in the developer/architect’s mind is generally to build a better architecture and these small features don’t seem important and mess up this beautiful new architecture.

Plus, however good the developers are, they will introduce new bugs that will only get exposed and fixed through usage.

The net result is that the product after the rewrite is, in the eyes of the end-user and the market, worse than the product before the rewrite, even if it’s better in the eyes of the developer.

This further pushes out the break-even point in terms of functionality and competitiveness of your product will take a long time to recover.  If you listen carefully, you can probably hear your competitors wetting themselves laughing at your folly.

What tends to go wrong – Part 3

Oh dear.

The nail in the coffin is that, not only does the rewrite take longer than expected, and functionality get lost in the process, but the benefits of the new technology/language/framework turn out to not be nearly as great as claimed.  Meanwhile, if you’d stuck with the status quo, you would have got more productive due to normal learning effects – i.e. don’t forget that while your team is climbing the learning curve with the new technology, you would have been getting better with the old one anyway.

Any one of the 3 problems above is potentially fatal but all 3 together is definitely so.  Competitiveness of your product will likely never recover.

Why does this happen?

So, the above sections discuss what can go wrong.  It might help to understand why this happens.

In Joel’s seminal post cited above, he makes the point, “It’s harder to read code than to write it.”

Very true – it’s also more fun to write new code than learn someone else’s code.

Developers like to feel smart and, intellectually, learning someone else’s code can seem like a lose-lose scenario to a lot of developers – if the code is bad, it’s painful to learn and you’re going to have to fix it.  On the other hand, if it’s better than you would have written, it’s going to make you feel stupid.

Also, bear in mind that the fundamental motivation of most (not all) engineers is to Learn New Stuff ™.  They are always going to gravitate towards new things over old problems they feel they’ve already solved.  Again, I’m not faulting developers for this – it doesn’t make them bad people but, if you’re a non-developer, it’s critical you understand this motivation.

Put it this way: would you rather be the guy that architected the Golden Gate Bridge or one of the guys hanging off it on a rope, scraping off rust and repainting it?

Another problem is that when you rewrite, you typically make rapid progress early on which gives false validation to the decision to rewrite.  It makes you feel smart – what a beautiful cathedral I’m building.

That’s because you’re writing code in a vacuum.  No one is using the code yet; certainly no actual users.  But, as you start to reach launch date, all those small features, tweaks and bug-fixes – all that learning that was encapsulated in your old product – starts to become conspicuous by its absence.

The bottom-line is that, when the case to rewrite is being made, it is not comparing apples to apples – it is comparing theoretical benefits with actual benefits.  The actual benefit in question being, of course, that you have an existing product that works.

Comparing the pros and cons of writing a new application in language A versus B is not the same as comparing an application already written in language A versus rewriting that application in language B.  Why?  because any productivity gains of one language over the other are typically massively overridden by the loss of all the domain knowledge, testing and fixes encapsulated in the existing product.

Should you EVER rewrite?

So, are there ever circumstances when you should rewrite?  My answer here is an emphatic“maybe”.

Let’s consider some of the possible situations:

1.  An irretrievably sick code-base
The symptom here is that it takes exponentially longer to add each new feature – per the chart above.  Another symptom is that defect reports continue to come in as fast, or faster than you can fix them – you’re treading water.
However, an irretrievably sick development team is a much more likely culprit than an irretrievably sick product.
Don’t let developers convince you that they can’t maintain a codebase – what they most often mean is that they don’t want to maintain a codebase.

2.  The developers who wrote the code are not available
If you buy/find/inherit a codebase, make sure you have access to as many of the developers who wrote it as possible, for as long as possible.  If you didn’t…doh!
Again, don’t fall into the trap – developers will always prefer to write new code of their own than learn how the existing code works.

3.  A genuine change to a new problem domain
Sometimes, some of the fundamental assumptions and technology choices may no longer be valid for the problem domain that your product is addressing.  But, then I’d argue, you’re really talking about building a new product rather than rewriting an existing one.

4. Fundamentally incorrect or limiting technology choices
In some cases, the team that originally built the product may have made some poor choices in the technologies to use or the approaches to take.  They may simply not map well to the problem domain of your product.  However, in my experience, this is true much less often than developers claim it’s true.
Also, there are points where you start to hit fundamental scalability limits of certain technologies.  However, keep in mind that if you’re hitting those scalability limits, someone else probably has too before you, and solutions to the problem exist.

So, if you are even entertaining the suggestion of a rewrite, make sure you get the developers to give you a specific cost-benefit analysis of the rewrite.  Show them the charts above and get them to tell you why these problems won’t occur in this case, even though they occur in almost every case.

If and when you are convinced that this is one of those rare situations where a rewrite is the right approach, you need to make it surgical:  where will you make the incision?  How deep do you cut?  What are the risks?  What are the potential side-effects?  How can I make sure no functionality is lost? How can it be done incrementally?

Divide the rewrite into a series of smaller changes, during which functionality absolutely cannot be lost.  Rewrite parts of the system at a time with a well defined, understood and testable interface between old and new.

Better still, don’t rewrite.

Good luck.

Agree, disagree?  Please leave a comment.