josephfung on September 26th, 2011
Editor’s note: This is a cross post by Joseph Fung (LinkedIn, @josephfung), the CEO of TribeHR (@tribehr). Joseph has recently raised $1MM from David Skok (@bostonVC) at Matrix Partners in Boston, MA. He is building and automating the SaaS metrics for TribeHR. He has a unique engineering view of sales and marketing that allows him to be nimble and correct his efforts based on real customer behaviour data. This post was orignially published on September 23, 2011.
Some rights reserved by Tim Gage
I’m of the opinion that the startup journey is really just the process of repeated work between “a-ha” moments of key insights. The faster we get to new insights, the better we are at ongoing improvement. I’m writing this post to describe an a-ha moment that happened early on (although earlier would have been better) in the lifecycle of TribeHR.
Figure 1: Exciting! An Arbitrary State Machine
To engineers turned entrepreneurs: your customer acquisition funnel is a finite state machine.
This statement implies three specific premises:
- your funnel can and should be modeled as a Finite State Machine (FSM)
- your funnel FSM should map to explicit in-app states
- investors care about the funnel state as much as (if not more) than anything else in your app
Your Funnel Should be Modeled
This point is best described in terms of my experiences with TribeHR:
When designing features within TribeHR, it was intuitive to think about our software in terms of moving objects through a series of states: a review was “in-progress”, “completed”, then “filed”; a vacation request was “pending review”, then “approved” or “rejected”. Similarly, the users of the system would also be moved through states – “employee”, “manager” or “admin” for example. When I thought about the marketing process, however, I treated “sales and marketing” as the entry point into the state machine – I saw it as the entry arrow rather than a separate series of states.
Because we didn’t start by planning our marketing and sales states, it was easy to rely on 3rd party services for our definitions. Unfortunately, implementing multiple services led to confusion. Some customers subscribed using PayPal, others paid through our payment gateway, and others found us via third-party app stores – each system had a different way of defining the state of a customer, so simple numbers like “how many customers are active” was a difficult thing to determine. This was compounded by our shift from a freemium model to a free-trial model earlier this year.
If we had clearly defined and tracked our states from the start (which we have since done) it would have been easier to map third-party terminology to our own, making analyses and improvements much easier. You can see the results of subsequent mapping in the diagram below:
Figure 2: TribeHR Funnel as a Finite State Machine
As you can see, our entry state is “trialing”, thus the primary objective of our website is to convert visitors and leads into trialing users (our lead nurturing program is a state-machine still being designed). Once someone is trialling, they have two potential transitions: they can become either a paid “active” customer or an “abandoned” trial. Once someone becomes an active customer (and ideally remain one for a long time) they will exit the state only as a “cancelled” or “suspended” account. By clearly defining our states in the above format, we are now much better equipped to modify our messaging and features to optimize the experience. Before identifying the above state machine, we wasted a lot of time manually analyzing and identifying states, often on a case-by-case basis.
The “should” part of my assertion follows from my conversations with investors and advisors. I’d frequently be asked for information such as our conversion rate from trials to paid customers or our re-activation rate of suspended accounts – without a clear FSM, we’d have some accounts that occupied more than one state, which made answering these questions impossible. By defining our funnel/FSM we were then able to answer such questions with ease, which made a world of difference to our working relationship with investors and advisors.
If you haven’t defined your Funnel/FSM yet – do so. If you’re early-on in your startups, ot might not be perfect, but it will save you significant stress, time, and effort as you continue to work with mentors and investors. If it helps, put the model up on the wall at your office – it’ll keep it top of mind with your team.
Mapping to Explicit In-App States
Once you finalize your model, it’s critically important that you then track these states explicitly within you app. For example, if you offer a 15-day trial, during which users have to cancel or continue, it might be tempting to calculate “trialing” customers as those who are subscribed and whose date subscribed value is within the last 15 days. While this calculation might yield a correct result, formulating queries becomes significantly more complex when you can’t simply evaluate whether a field “state” is set to “trialing”.
These queries are important because as your company and customer base grow, you’ll need to generate reports and dashboards that highlight this information in near real-time. You’ll need to answer questions like what percentage of users that sign up for a trial convert to a paid customer, and how is it changing over time? As soon as you can answer that, you’ll then be asked to segment by lead source, user characteristic, or time window. For example how does that conversion rate over time vary according to lead source or engagement level?
To put it into an example, below are two examples of queries that would generate a summary of states of a single cohort from January 2011, assuming a 15-day trialing period. The first uses explicitly defined states, and the second assumes you calculate a real-time trial period, and simply delete records when they terminate their account.
Explicitly defined:
SELECT COUNT(state) AS total_users, state
FROM users
WHERE date_registered >= "2011-01-01" AND date_registered < "2011-02-01"
GROUP BY state;
Calculated on the fly:
SELECT SELECT COUNT(state) AS total_users, IF(date_registered >
DATE_SUB("2011-02-01" , INTERVAL 15 DAY); "TRIAL"; "ACTIVE") AS state
FROM users
WHERE date_registered >= "2011-01-01" AND date_registered < "2011-02-01"
GROUP BY state;
As you can see, the query in the first is much easier to use and read, and it includes all states, whereas the second is challenging to use (even more challenging to modify if you have more states) and doesn’t track cancelled accounts.
By structuring your database such that the state is explicitly identifiable, you’ll be able to generate queries much more readily, which will then let you automate standard reports (like conversion and churn rates) for dash boarding, and will allow you to more easily connect business intelligence tools to your database. The ultimate goal is to let your business-oriented team members manipulate the data as readily as you can.
An added benefit of explicit states is that they act as assertions. Although it’s possible to determine that a customer is active by checking the date of their last successful payment, it’smuch better to have an explicit “active” state as you can then run automated tests to verify that your assertions are true. Having a recurring task that iterates through your customer base to confirm that accounts with a most recent payment made within the last month are correctly identified as “active”, is a good way to follow monitoring-driven-development approaches. Any assertion errors can help identify critical flaws in your system.
Investors Care About the Funnel State
Although this may seem obvious, it still needs stating. The platitude what get’s measured gets done has a corollary – what we care about gets measured. Technical founders often measure and know details like server load, traffic metrics, lines of code and number of commits or push requests. Because we innately care about those tasks, we tend to measure and follow them. What can’t be over-emphasized is how much investors, advisors and partners will care about your funnel states. Below is a representative subset of the metrics we’ve been asked to report at our board meetings – you’ll notice that none of them are related to in-app usage or infrastructure performance:
- Total # Of Customers (overall and by customer segments)
- Visitor-to-Trial Conversion Rate (overall, and by lead source)
- Trials-to-Active Conversion Rate (overall, and by lead source and by segment)
- Churn Rate (overall and by lead source)
- Customer Acquisition Cost (overall and by lead source)
- Average Revenue per User (overall and by lead source)
- Life Time Value (overall and by lead source)
Most of these numbers depend on measuring our customers’ states as well as various additional segments. Because our segments will vary frequently as we experiment and optimize with marketing campaigns, if we don’t have explicit (and easily determined) states, rapid iterations on our reporting become exceptionally difficult.
Investors and advisors will assume that you have infrastructure running smoothly – you don’t need to hammer home evidence of it, so skip on reporting the infrastructure stats I mentioned earlier. For them to provide valuable advice, however, they need to be able to understand and trust the business metrics I listed. If you can speak as confidently about your Funnel/FSM as you do your application, and if you can deliver transparency into the funnel by automating reports and dashboards, you’ll build your investors confidence and trust in you as an entrepreneur.
Bonus Reasons
As a bonus, here are a few cool things you can then do once you have this funnel modelled and embedded within your software:
- More easily build dashboards with tools like Geckoboard
- Delegate data-mining and analysis to non-technical staff, by tacking on BI tools like Qlickview
- Automate segmentation and lists for automated email campaigns and lead nurturing using Mailchimp, Performable, and others
- Simplify cohort analyses by customer segment
If you have a state machine for your funnel or customer base, especially if it deviates significantly from mine above, please share it in a comment or an email to me. It would be interesting to see what approaches others are taking.
Editor’s note: This is a cross post by Joseph Fung (LinkedIn, @josephfung), the CEO of TribeHR (@tribehr). Joseph has recently raised $1MM from David Skok (@bostonVC) at Matrix Partners in Boston, MA. He is building and automating the SaaS metrics for TribeHR. He has a unique engineering view of sales and marketing that allows him to be nimble and correct his efforts based on real customer behaviour data. This post was orignially published on September 23, 2011.
