A systems look at the variables in a successful SaaS product

A while back I shared a version of this rough and ready systems diagram looking at a system to manage new product development priorities where the situation of interest is the need to create new revenue streams to diversify. 

 

Note: It doesn't fully follow the conventions of Systems dynamics and is firmly grounded in a B2B SaaS context. This formed the basis of a Systems Thinking assignment that I did, so sharing a bit more here in case anyone has any comments or suggestions on my exploration of this space.

It kinda felt right, yet the focus felt it was off. So, I then used the 12 boundary questions from Critical Systems Heuristics (CSH) to think about the system again from other viewpoints.


Source of influence

Who should be the stakeholders?

What’s at stake?

Stakeholdings: constraining or developmental?

Motivation

(beneficiary)

Business owners

 

Business sales team

Software users

(purpose)

Maximise profits from customers

 

Solve the business problems of the customers

(measure of improvement)

Profit margins

 

Customer lifetime value (LTV)

Control

(decision maker)

Business owners

 

Marketing team

(resources)

Capital

 

Labour

 

Marketing budget

(decision environment)

Business plan

 

Company budget

 

Expertise

(expert)

Product Managers

Support team

(expertise)

 

User research

 

Prioritisation

 

Identifying changes required from support issues

(guarantor)

 

Future profitability?

 

Product/market fit

 

Reduced support overheads

Legitimacy

(witness)

Existing Investors/Business Owners

 

(emancipation)

 

Business does not require external investment to grow

(worldviews)

 

Non-dilution of company ownership

Table 1. descriptive mapping from CSH

This was refined to “A system to prioritise valuable activities, by product management in a software development company, to increase profitability while growing”. There are two key variables related to the financial success of the company sales (the blue node) and profitable features (the green node). These are both part of loops that exhibit signs of the limit of growth archetype. Along with the process of servicing existing customers these will be discussed in more detail.

Growth engine - sales

This process is the main growth engine of the company. More sales result in more customers. This is driven by new product development opening up customers, and providing marketing material which leads to an increase in marketing spend. Assuming this marketing activity is effective there will be an increase in conversion of leads into sales.

Limiting process - cost of sales

Alongside the growth engine in sales is the limiting process related to the cost of sales. Here limited to the marketing aspect. If the new product development requires a lot of new marketing activity then the marketing budget will go up, reducing the amount in the company budget for other functions including investment in new product development or developing other features.

Profitability engine - recurring revenue

The second financial driver is the profitability engine or recurring revenue. Here “profitable features” are those features that have been developed and are used by customers that then stay with the company. There is a delay in detecting “unused features” via usage data, which when removed reduced the maintenance overhead. Leading to high lifetime value of a customer as on a simple level profit = revenue - overheads.

Limiting process - churn

To maximise the value of a customer to a company an important variable is the lifetime value, so churn will influence this after a delay. This delay is assuming both that there is fixed initial contract terms and notice period, and that this notice period is given some time after the product is not used by the customer.

Limiting process - servicing existing customers

There is another limiting process to growth here labelled “servicing existing customers”. As the customer base grows, both in terms of absolute numbers of customers and different customer segments, there will be gaps in what the product does and what the customers need it to do. For example, a change in data regulation requirements may change the customer’s operating environment as GDPR did in the EU. There will be a delay in these being identified by the customer, or support team, and being raised as a change request.

Reflections on using Systems Thinking

Making strategy with systems thinking in practice was the first course that I had done that was in the emic enquiry approach rather than etic, that is the researcher acknowledges that they are part of the system under investigation. This is incredibly useful frame of reference for anyone involved in internal change management or transformation efforts.

Compare this to being an external consultant or supplier, where as in etic approach you are external to the system under investigation and finding an objective "truth". Emic enquiry looks to navigate the subjective reality, for example in the case above, each team would have a different perspective and the research looks to reconcile the relevant areas. So, that there is shared understanding of the impact of any changes. Optimising for a part of the system could (and IME often will) lead to unintended consequences.

So my diagrams and exploration of the loops in Product Development above aren't a statement of "objective truth", but rather sense making of a subjective reality and consideration of where best to apply a change.

Further reading

Comments

Post a Comment

Popular posts from this blog

CONFERENCE: TTI Summer Forum 2017 – Getting to Grips with GDPR

On performance and environment

On HBX and online education