Systemize ftw!

Our process for taking over the product can be broken down into 5 stages, and our goal was to complete them in the first 30 days.
Transition - Take over the product, accounts, responsibilities
Stabilize - Ensure the business is stable, robust and fortified against interruptions and downtime
Deep Dive & Instrument - Research and understand what's happening today
Quick Wins - Act on any low hanging fruit that exists
Steady State & Iterate - Operate on a steady rhythm of profitable growth

We've completed the transition activities, making good progress on the stabilize activities, and nearing completion on deep dive & instrumentation. The team's excited about the low hanging fruit that's been discovered and eager to progress to the "quick wins" phase to start executing on some of them.

In advance of executing on the "quick wins" theme, this week we introduced the key drivers worksheet.

The worksheet is built on a generic model applicable to most SaaS applications, and highlights the major levers which can be applied in order to grow. The major ones are:

Site traffic - How many visitors do we get on a monthly basis?
Site>Trial Conversion - How many of those visitors signup for a free trial
Trial>Paid - How many trials convert into a paid subscription
Churn - Of our paying customers, how many churn out
Price* - What do we charge for our product

• Price is a simplistic measure in this case, as we're ignoring the growth opportunities from both upsells and expansion revenue for the moment.

SINGLE THROAT TO CHOKE
(to borrow an anachronism from a less woke era)

Each metric must have a SINGLE owner associated with it. In the case of metrics with multiple owners that seem to make sense, the metric will be broken down.

For example, our customer success manager will be responsible for reducing inactivity churn (subscribers who aren't using the product and then quit), whereas our full stack developer will be responsible for reducing product churn (subscribers who run into a bug that prevents them from realizing value, and then quit).

SYSTEM VS GOAL THINKING
The conversation that resulted from this sheet turned into a discussion on systems thinking vs goal thinking. Where systems thinking is to track activity, with the confidence that that activity will result in the goal being achieved. Examples of system thinking include:

• It takes 100 phone calls to land a sale.
• If I write 10 blog posts, it'll increase my search ranking
• Etc.

Goal thinking is the opposite. With goal thinking, you start with the goal (reduce churn by 5% per month!) and then work backwards to identify the activities needed to achieve that goal.

For example, to reduce churn by 5%, I might try the following things:

• Order the product backlog to focus on bugs affecting the most users
• Update user onboarding workflows to highlight new features to increase engagement
• Initiate email nurturing campaigns for users on certain product triggers
• Etc.

There's an important benefit to goal thinking as it relates to hierarchies.
Rather than the boss doling out work assignments (Make 100 calls!), the goal is assigned (reduce churn!) and the activities to achieve that goal are left as an exercise to the goal owner.

Crucially, this forces the goal owner (the worker bee, in this context) to come up with the activities themselves, which inherently gets them more engaged, and take more ownership for the ultimate success and outcome of the goal.

The key drivers sheet was well received, and after the meeting, some team members commented on being fired up from seeing "how" we were going to make Goodbits successful. Cool!

Next step, we'll be assigning owners to each metric to each metric, then work with the individual team members to jointly come up with targets to hit.

Onwards!