#ERROR!
Dashboards For Startups
Collecting, collating and communicating progress against objectives is a key task of CEO's. Hypernumbers are developing a product to address the pain of doing that manually by allowing spreadsheet users to 'applicationise' their spreadsheet models. If you know what you want, try the demo – if not read on.
Introduction
Communication is one of the key tasks of a CEO – communication to keep the team aligned, to keep the investors happy, to get the most out of the advisory board – and critically communication to get the right communication back. This article will look at the use of dashboards to do that communication as part of Lean Production in the context of the ‘emerging startup business stack’ shown below:
The CEO's Job
The focus will be on a particular pair of jobs that the CEO must do. Firstly setting objectives and then building an organisational culture where people work towards those objectives autonomously without supervision.
Problems With Comms
Before progressing with the discussion it is necessary to slaughter some sacred cows.
There is a constant meme in startup land about agile startups and ponderous corporations and this is usually expressed in terms of personality and human attributes. ‘Scrappy, fighting, entrepreneurial startups’ versus ‘bureaucratic, stodgy, risk-averse corporations’. There is a kernel of truth in this cliché.
Startups compensate for long hours and low wages (in part) by flattery (you’re great, we’re agile, we’re smart, they’re dull, boring and bureaucratic) but it important to separate this particular self-delusion from the facts.
There is a fundamental difference between a small organisation and big one. There is another fundamental difference between an organisation with a precarious and uncertain income stream (or none at all) and an organisation with a predictable, structured and regular one.
Given that most startups aspire to go from being small and uncertain to large and profitable then ‘becoming just another large company’ is the classic problem of success – we should have those problems.
There appears to be a natural limit for groups of humans working on a common purpose below which multi-part communications is natural, fluid and automatic, and above which communications becomes problematic, requires work and considerable effort to make happen. That limit is somewhere in the region of 19.
But startups also go through a very different change – from looking for a business model to trying to optimize a business model. It is important to separate these two effects – they both impact the CEO’s job, but in different ways.
Methodologies, Objectives, Metrics, Tools, Techniques And Tasks
To make sense of how the emerging business stack in the diagram at the top of this article fits together it is worth calling on Kipling's six honest serving men.
I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who.
Rudyard Kipling The Elephant’s Child
When
When do we do things?
Methodology
A statement of dependencies – if you don't know what you are selling yet how can you sell it, etc, etc
What
What are we trying to achieve?
Objectives
Sean Ellis's Startup Pyramid
A statement of the conditions that, if met, let you move onto the next stage of the methodology
What
What are the customers doing?
Metrics
Initially an idealised representation of the customer lifecycle that you can test against - but eventually reflecting a profitable customer lifecyle
Why
Why are the customers doing what they're doing?
Analytical Methods
Dave McClure
Quantitative, Qualitative, Comparative, Competitive
How
How do we know why the customers are doing what they are doing?
Tools And Techniques
Dave McClure
A million different companies
Who
Who does what?
Tasks And Organisational Structure
Each line in that table is (literally in some cases) a book in its own right – if they are not clear to you now you should probably familiarise yourself with them before continuing to read.
How They Are Related
Objectives, metrics and tasks are only loosely related. Indeed organisational pressure often selects for core metrics that are almost entirely detached.
It is worth taking a particular example from outside the internet industry to make that point. Consider the role of symmetry (and beauty) in mammalian courtship.
The mammalian embryo undergoes some considerable metamorphoses in the womb. Development and symmetry in embryology is controlled by hormone diffusion and concentrations. The initial embryo develops with a particular symmetry to reflect that. But mammals evolved from flatfish, and flatfish undergo a complex flip where their eyes rotate around their head and their body breaks its original symmetry and gets a second plane of symmetry – the plane of symmetry of our internal organs is different to that of our external ones (compare and contrast this to say, a crab or starfish). This second set of symmetry develops later and is considerably harder to pull off – it is a developmental rather than an intrinsic symmetry.
The consequence of this is that there are 50,000 things that can go wrong in the womb which lead to that symmetry breaking – and thus symmetry (and hence beauty) is strongly indicative of reproductive health.
Organising around so-called hygiene factors is also a feature of many operational methodologies. In the original car production techniques of Toyota the production line was the key indicator of overall operational health.
In the Western canon only the management could stop the line (and bring the entire factory to a grinding halt) - and heroic efforts were made to keep the factory running (what we would call firefighting). The underlying problem would not be fixed but would continue to happen.
In Japan any worker could stop the line and was encouraged to do so if their task had gone wrong. There are 50,000 reasons why the Toyota production line might stop – and only by stopping the line would you get sufficient focus on the problem to fix it so that it didn’t happen again.
In Lean Startups, continuous (and automated) deployment of software changes to production performs the same role. The ability to develop a software fragment and deploy it live to production (without a large number of intermediate quality assurance and testing steps) is a strong indicator of good operational software development practices, including, but not exclusively:
• a strong architecture
• empowered software developers
• good development techniques
• code review
• documentation/understanding of the system
• appropriate unit and system test coverage
• correct bug triage, fixing and root cause analysis
• and so on and so forth
Likewise in the pirate metrics methodology the 5 measurements of Acquisition, Activation, Retention, Referral and Revenue all stand for the actual things customers do – they are strongly indicative of a functioning business model – but failure of those metrics to meet appropriate targets tells you very little – your company can be broken in a gazillion different ways.
Tolstoy once said “all happy families are alike, but every unhappy family is unhappy in its own way’ – well here comes my corollary: “all companies with a functioning business model are alike, but every company without one is broken in its own way”.
The whole of the customer discovery/customer validation/iteration/A-B testing processes can be considered one of making the abstract customer lifecycle of AARRR (come, do stuff, hang about, tell someone, pay) with a concrete lifecycle (come to do this particular task via one of these channels, do this (but not that), perform these tasks with this value and this recurrence, inform (deliberately or incidentally) these types of people with this propensity to become customers and finally pay out cash right up to the value point that the product delivers to them).
There is a startup I know of that provides invoicing for small businesses. The specific customer action that expresses their business model is this: “if a customer issues 2 invoices with the freemium system they are 85% likely to become and remain paying customers” – the journey from ‘doing stuff’ to that statement is the journey of customer development.
The Dashboard
For the company to work effectively all parties (staff, executive, investors, board members and advisory board members) need to have a common view, both of what the company is trying to achieve (the product and market vision and the current objectives) and its progress against those objectives.
The dashboard is simply a collection of statistics over time which make it clear to all parties how the company is progressing (or not) as a whole - whether at the weekly team meetings, the monthly all-hands or the bi-monthly board meetings.
In the early stages the metrics are generic and largely broken (conversion rates of 0% early in the pipeline masking downstream problems and so on). If your software is totally flaky it may include metrics that are not properly part of the customer lifecycle (for instance uptime). There may be private operational metrics (like time through a build-learn-measure loop). But generally there will be a small amount of metrics (may 10 or so).
The key part here is not to be the little girl in The Elephant’s Child.
She sends 'em abroad on her own affairs,
From the second she opens her eyes—
One million How’s, two million Where’s,
And seven million Why’s!
Your operational systems spew out data – firehose it out – and you can drown your communications in irrelevant detail. You might have data in Google Analytics, Kiss Metrics, your payment pipeline, your own application and a dozen more services and supporting bits and pieces.
Once a company has a fully developed business model the picture is radically different – the top level EIS deck will probably only have about 10 headline measures, but typically it will allow management to drill down (and down and down) into detailed metrics.
When you are starting out everything tends to be a bit binary (no users to some users/no customers to some customers) but when you have a mature model there is considerable more nuance. Raising a critical conversion rate from 4% to 5% might see a 20% increase in gross revenues and a 30% rise in margin. To a company like Google shaving home page response times by milliseconds turns into big moolah – but probably not for you (yet!).
Implementing Dashboards
At the bottom end of the chain, implementing dashboards is a scoosh – you use a spreadsheet (or a magic whiteboard) and everyone stands around it. When your metrics changes (as they will) you just change the spreadsheet on the fly.
At the top end of the chain you just hire three metric busloads of stats monkeys who knock you up an OLAP cube and you are away. Your metrics changes much more slowly and are deeper and more complex and get an operational department in their own right.
It’s the bit in the middle that’s a pain in the neck, so if you meet one of these criteria you might have problems:
• you have more than 20 employees
• your employees are on more than 1 site (or are remote workers)
• you have hands-on advisors or board members who want to have data to hand
The pain you have is that it is not cost effective to productionise your dashboard because the metrics and the systems that provide them are in a state of constant flux – the over-riding objective of the company is to replace the generic customer lifecycle metrics with actual as-yet-unknown concrete ones supported by inline and automated measurements from production systems.
All hands turn to the trusted spreadsheet and figures are cut’n’pasted out, email around, read off consoles and aggregated.
As soon as your metric deck expands from measurements to ratios (average cost per customer, etc, etc) the spreadsheet suddenly needs to be curated (when you enter your data don’t break my formulae). The problem is that for a startup the ‘my’ in ‘my formulae’ tends to be the CEO and one of two things happen:
• the CEO is spending 20% or 30% of their time as a spreadsheet jockey
• the cycle time for the figures goes out (we only produce our metrics for the monthly board meeting because it takes 3 days per pack)
However simply creating a dashboard isn’t the end of the problem. An effective distributed dashboard should be encultured in the organisation such that the various parties perform their data entry tasks without continual prompting and reminders from the CEO. The use of the dashboard needs to be ingrained in the operational tempo of the company such that people do it because ‘that is how we do things around here’.
What Hypernumbers Are Trying To Do
Hypernumbers are trying to solve the technical part of this particular curation/collation/aggregation problem.
There are three basic roles in an organisation with respect to operational spreadsheets:
• designers - who build and specify the spreadsheet (in this case the CEO)
• data providers – who provide data (head of IT, head of UX, head of SEO, etc, etc)
• data consumers – who consume the results of the analysis (board members, advisors)
With the hypernumbers team spreadsheet each of these basic roles gets a different view of the (multipage) spreadsheet:
• designers get a full spreadsheet
• data providers get a wiki view that allows them to enter data into specific cells only (and there can be multiple providers of different data with their own permissions)
• data consumers get webpage views that allow them to read the information only
Do You Feel This Pain?
The Hypernumbers Team Spreadsheet can, like any spreadsheet, be used for any number of purposes. Our initial focus is on finding one particular use that we can nail down completely.
Our first use case is the collection, collation and publication of operational data for internet startups. We are looking to put together a small collection of customers who have that specific problem and for whom we can focus on nailing this problem.
Some of the areas we would expect to explore with these particular customers include:
• pulling data from commoditised and common operational systems automatically
• creating specific dashboard graphs and reporting components
• etc, etc
In addition we would consider looking at keiretsu dashboards – where data from a number of startups from the same incubator, or which have had investments from a particular organisation, created a pooled dashboard so that they can compare, for instance, their CPC with peers in similar market sectors to them. (An example might be an investor who has 5 or 6 facebook-focussed companies).
If you sign-up for this ‘dash board product demo’ we will give you three months free – that is 4 months standard subscription for $39.99 (a saving of $119.97). This comes with the standard 31-day no quibble refund.
#NAME?
To take part in this you will have to agree to 3 things:
• take part in a detailed customer discovery call (or calls) so that we can really understand your pain points
• bombard us with feature requests that would really make your life easier and criticisms of weak points of our software
• pressure us to get maximum value for money out of your investment
We look forward to working with you. If you have joined the beta dashboard programme and paid your subscription we will be in touch. Just head over to the demo page and get started.
About The Author
Gordon Guthrie (gordon@hypernumbers.com +44 7776 251669 or Skype gordon_guthrie) is CEO of hypernumbers.com. During Web 1.0 he was Chief Technical Architect at if.com – an internet bank which took 10% of the UK mortgage market in its first 18 months.
#ERROR!