Your managers want to measure all kinds of interesting pieces of data to run the company well. Much of that is reflected in your organization's Profit and Loss (P&L) statement. (There's a great site with an explanation of a P&L statement.)
Notice any organization's three big numbers: Revenue, all the operating expenses, and net earnings.
Do you know how to link those numbers to your team's measures? It turns out that the Pirate Metrics and the flow metrics can work together to link those measures.
First, the Pirate Metrics.
Dave McClure's Pirate Metrics Are a Good Start
If you're not familiar with McClure's work, here is the original Slideshare and his video. The Pirate Metrics are:
- Acquisition (of a customer): How long does it take to acquire a customer, and from where? (All the places where you market or promote your product to your ideal customer.)
- Activation: Does the customer use the product? Or how does the customer use the product?
- Retention: Does the customer continue to use the product? (Think about the lifetime value of a customer to the organization.)
- Revenue: How do you make money with this product? (Sometimes, in startup mode, managers think they can lose money on each sale and “make it up” in volume. I've never seen that work.)
- Referral: When customers tell other potential customers about your products.
I like to think of the Pirate Metrics as a focus on revenue, and the ability to increase revenue over time. However, they do not specifically affect operating expenses, interest, or taxes, other key components of the P&L statement.
Expenses Matter
How much does it cost your organization to produce the product? That's the idea behind expenses, especially operating expenses.
In my experience, many managers want to decrease operating expenses. There are two common ways to decrease operating expenses:
- Reduce headcount. That's a fast way to reduce operating expenses. (However, that often leads to a reduction in the number of products and projects, never mind the various Cost of Delays for waiting for people to be available to do the work.)
- Move operating expenses to capital expenses. (That's a move from OpEx to CapEx. See this site for a good discussion of CapEx and OpEx.)
CapEx helps the organization manage its taxes and depreciation better. (Depreciation is the ability to “write off” expenses because the company now has an asset.) That's why your organization might want to move from OpEx to CapEx for managing expenses. That all depends on every team's ability to finish value and release it relatively fast.
However, expenses are not the only issue. What does the company earn for its operating and capital expenses? Many organizations measure EBIT (Earnings Before Interest and Taxes) or EBITDA (Earnings Before Interest, Taxes, Depreciation, and Amortization). (See the Investopedia page for more details.)
Earnings Before Interest and Taxes (EBIT)
I am not a fan of measuring EBIT or EBITDA. In effect, that's a measure of “raw” profit. (My term, not any finance person's term.) To me, that feels like using relative estimation to estimate. Sure, it's a measure of something, but not anything you can use for prediction.
I'm not big on EBITDA, either. I love measuring cash-generation potential. But that's just potential, not reality. Again, way too similar to relative estimation for me. A magical number that might not be related to any reality at all.
I'm also not the one running your organization, so feel free to dismiss my opinions.
To get a higher EBIT or EBITDA, you need to release more value, more often, and get more revenue for that value. That value might allow your company to attract and retain more customers. (See that link back to the Pirate Metrics?)
However, the flow metrics can help everything on the P&L, especially if you think about the Pirate Metrics for raising the top line (revenue). Flow metrics support the numbers managers want to see.
Flow Metrics Support Management Desires
If you are new to flow metrics, please read Flow Metrics and Why They Matter for Teams and Managers. The flow metrics are:
- WIP: Work in Progress
- Cycle time: How long it takes a team to release finished value to a customer. (Someone who can use that value.)
- Throughput: How many items a team can release over time.
- Aging: How long work stays in progress. The higher the aging, the longer the cycle time and the lower the throughput.
(I've written about this also in Little’s Law for Any Kind of Product Development: How to Learn How Long Your Work Will Take.)
If your company wants to use CapEx, every team needs as low cycle time as possible and as high throughput as possible. That's the fastest way to move to higher capitalization. It also means there is more chance to use the Pirate Metrics to get new customers and the revenue from them.
That means managers should want highly collaborative teams focused on very little WIP, where they deliver value as early as possible. My most recent newsletter, How to Use Delivery to Move from Blame to Trust, explains a little about that problem. That would allow organizations to manage with flow metrics even if they have to report their cost accounting data.
And that's the culture clash of agility with resource efficiency.
Cost Accounting Focuses on Individuals, Resource Efficiency
Your managers ask you for velocity because they think that's throughput. Nope. It's not. Worse, they might ask you to measure “individual” velocity, as if any team could know who is more “efficient.”
Product development of any kind requires collaboration. Collaboration enables low cycle time and high throughput, especially if the team pairs, swarms, or mobs. Instead, when managers focus on individuals, they create higher WIP and longer aging—exactly what the managers do not want.
This is why an agile “transformation” requires a culture change from resource efficiency to flow efficiency thinking. The longer managers focus on individuals, the less likely the organization can foster any agility.
Is there a way to change? Yes. And as always, start with yourself (as a team).
How to Consider a Change
I rarely challenge managers to change their minds because I haven't found that effective without data. Instead, I ask the teams to measure their cycle time with value stream maps. The cycle time helps the team see how long things really take and why. The value stream maps show who else the team needs, and the waiting costs. (You can convert waiting costs to Cost of Delay.)
Now, with cycle time measures, the teams can start to create their estimation probabilities. See How to Move from Story Points and Magical Thinking to Cycle Time for Decisions.
What impediments does the team have for faster cycle time and higher throughput? Work on those issues as a team and ask managers for their support. This actually improves the team's influence with managers because the team shows its competence.
Once the team has a few weeks of data, with lower cycle times and higher throughput, the team can now draw the links between the P&L and the team's measures. Here's how I've started those conversations:
- Want more revenue? We need to release value faster. Here are the delays that cause us to take longer. Here's what those delays cost us.
- Want to capitalize faster? We can release value faster if we have smaller items and can deploy on our own. Here are the impediments to CapEx.
- Want to decrease operating expenses? Instead of decreasing headcount, here are all the Costs of Delay that prevent us from finishing small work fast.
Link what you can do to what managers want.
Learn What Your Managers Want
If managers learn anything about finances at all, they learn about cost accounting. But cost accounting does not account for knowledge work. (It started with slavery. Read Accounting for Slavery by Caitlin Rosenthal. That's a universal book link with my affiliate codes.)
I wish I could see an end to cost accounting. Right now, I do not. Instead, help your managers manage better with the flow metrics. Help your managers make the link from what they want to the flow metrics. Then, you can deliver better and give managers what they want.
As a person running an organization (professional services) and typically working for product organizations, I’d make a few assumptions explicit here.
The pirate metrics are relevant for a product organization. Not so much for a service or a relatively small project-based company.
For a small project organization, the variability of time and size of projects combined with relatively few data points make AARRR either an overkill or irrelevant depending on a point of view. That is, unless you’re dealing with a large number of concurrent projects, or projects are relatively uniform (well, one implies the other).
If we put aside the gig economy, for a service organization is almost irrelevant. Even the way it is phrased suggests a different target group.
On the other hand, flow metrics would provide more value where the pirate metrics fall short.
In a project where we have a fairly well defined set of tasks that counts as an outcome, looking at the flow and throughput will be the best indicator how well we’re doing. That, in turn, should directly translate to P&L depending on the contractual terms. So if we have a reliable data from the whole portfolio of projects, we should have a decently accurate forecast for our financials.
However, I would intuitively downplay the value of the flow metrics in a product organization. Not that it would tell any less. However, the biggest issue in product companies is not the efficiency of building stuff but building the right stuff.
I see the most waste not in development process but in building too much, and wrong things. In such a case, we can have the flow metrics all green and shiny and still end up in a sad place.
Finally, the professional services org is an oddball here. On a company level we don’t really need the flow metrics any more than the pirate metrics.
The costs are predictable. We know who we have on a payroll.
The revenues in a short-term are predictable, too. We know who will work for which client for how much more time.
What we want to optimize for is client’s satisfaction. In other words, we want our customers to be satisfied with the value they get for the money they pay. If that’s true, they’ll keep working with us as long as they have a need (whether the throughput was excellent or just good).
In either case, I second your suggestion to pay attention mostly to costs, revenues, and net profit. These are, in fact, the only three numbers we focus on in our P&L.
If the business is healthy (or is on its way to be so) the combination of trends across these trio will show it.
The rest is the job for accountants who definitely can sugarcoat some stuff. But they won’t turn crap (unsustainable business) into a Fortune 500 company.
Pawel, thanks. I agree with you, especially about the types of organizations I did not specifically address.
Your point about building too much and building the wrong things is exactly right. We don’t have enough experimentation to see if what we’re building matters before we spend (too much) time building it.
That’s often a function of optimizing “down” to make sure people are busy instead of optimizing “up” for product strategy and the big picture for the organization. I keep hoping the flow metrics will help people with that, but I don’t think that’s enough. (Or even the right approach.)
I will have to experiment more.