Finance for Designers
(and Engineers, PMs, other product-building people).
hello! I'm back! At the beginning of April I caught COVID (first time since it started) and it really knocked me out for a few weeks.
Earlier this week I spoke at ConveyUX about "Translating Design Goals to Business Needs - Helping Leadership Understand the Value of Design." I also gave a preview of this talk at Ladies who UX Boston. The talk addressed the top five complaints I hear from my friends in Design, and was inspired by many of my conversations with Alyshia Olsen. I'm going to break them into pieces of writing because each half is already very long.
This week is "finance for designers (and other value-creation roles)." If you've ever thought "everyone only cares about finance," "I keep getting asked to drop everything to hack together one deal," or "ugh, why do we have to grow?" and have no better answer than "capitalism" - I hope this answers some of your questions.
Next week will be more focused on the impact of designers. If you are a designer, or work with a designer, subscribe for some more effective ways to collaborate.
As always this has a skew towards startups/fast growing tech organizations.
Top Five Complaints from my friends in Design
Everyone only cares about finance.
I keep getting asked to drop everything to hack together one deal.
No one takes me seriously when I bring up real user problems.
People just want me to push pixels.
I don't get brought into the process early enough.
Valuation: DCFs and Multiples
Before I went to business school, I had very little sense of "why" a company was worth as much as it was. It seemed like an arbitrary number created by the popularity of a stock (FOMO) and/or a venture capitalist.
Companies rely on three financial statements:
The Balance Sheet (how many assets and how much debt you have),
The Income Statement (how much money you make),
The Statement of Free Cash flows (how much cash you have available, which isn't always the same as assets since not all assets are liquid).
If you know how to read them, you can learn a lot about how a company operates.
DCFs
One of my favorite things from business school was learning to use the income statement to create discounted cash flows (DCF) as a method for valuation. I don't think it's useful for most designers (or engineers, or PMs) to know how to do this, but it did make me feel a lot better that there's a concrete method to calculate how much something is worth.
The fundamental idea is that the company is worth the amount of all of the money it will make (profit) into perpetuity. Money now is worth more than money later, so for each additional year in the future you "discount" the value of that future income. (If this doesn't make sense intuitively, it's the inverse of the idea that if you put money in your 401k now it will continue to accrue compound interest). You can also work in assumptions about if revenue will grow from new products, costs will decrease/increase, etc.
For a very simple example if you assume a company is making $10M/year in profit today, and will make $10M/year in profit forever, and money is worth 15% less for each year in the future, it would be worth about $60M.
While there's still a lot of assumptions in a DCF, you can vary them and get a pretty good idea of how much you think a company is worth.
This means that when a company talks about revenue and value, it's assumed that something like "future good design" is already baked into the model.
The value isn't about what you've done so far, it's about everything you think you'll do into the future. It's not that people only care about finance, it's that they assume finance is a common denominator that takes into account all of the work that's being done.
Multiples
DCFs are complicated, which means many professional investors instead rely on "Multiples."
Multiples is the idea that at scale, companies within the same industry are likely to have similar cost and revenue profiles. For example, if you build out a lot of grocery store DCFs, you're likely to find that they are typically valued at .1 - .5x top line revenue (grocery has very low margins). On the other hand, tech typically has very high margins and it's common to find revenue multiples between 10x and 100x (typically larger for earlier stage companies).
There are lots of different types of multiples - they can be any ratio. For instance, Price to Earnings is an example of a common multiple for public companies (you can see it reported on the bottom right here).
I'll only refer to revenue multiple here, because for private tech companies, multiples are most likely to be calculated on revenue.
The later stage the company, the more you'd expect the multiple (valuation/revenue) to be close to public multiples in the same format. If you've heard about a "market compression" lately, that means that public multiples went down, so investors are revising assessments of the value of late stage companies. One consequence of this is that later stage companies can have trouble raising more capital (especially if the multiple was very high before).
If you look at a Series B startup:
If it has $500k of ARR with a valuation of $50M, the multiple is 100x.
If it has $5M of ARR with the same valuation, the multiple is only 10x.
If you think of a company that supposedly had a Series B valuation of $500M with ~$600k of revenue, the multiple would be 833x (they would have needed to grow a lot!)
Multiples tend to be higher early on because the venture model assumes the company will grow dramatically. There's a lot more to get into about venture in particular and how the industry relies on dramatic growth, that I think is out of scope here (if you want to get into it, I recommend "The Power Law").
A simple way to think about it is when you raise money at a given valuation, if the multiple is high, you've already opted into the notion that the company will grow and revenue will increase in order to come back in line with public market multiples. The valuation wasn't based on what you did, it's based on the promise of what you will do.
At the end of the day, the same core idea from the DCF is here, too:
Everyone's work factors into generating the revenue. It's not good design OR revenue, it's that good design should be factored in as increased revenue.
Revenue
If you got anything out of the last two sections, it's hopefully that revenue/income is the marker that people will look at to see how much a business is worth. Companies will often talk about revenue at all hands and many designers/engineers I know will glaze over without the context.
A few handy acronyms:
ARR: Annual Recurring Revenue; how much money you make per year
MRR: Monthly Recurring Revenue; how much money you make per month
ACV: Average Contract Value; how much money you make for each new deal/customer
Often a company will internally share the current revenue number, as well as a goal for the quarter.
When talking about revenue, it's important to keep in mind that companies operate on a Fiscal Year/Quarter, with strict reporting standards. While as an engineer/designer, if you finish something up Monday morning before planning, it's probably nbd. Likewise if an incident comes up and all the work gets punted a week, people understand.
For a deal, "well we were mostly done on Friday, so let's put the date as Friday" doesn't cut it - it's fraud. It ends up being booked for the next quarter, which will impact last quarter's revenue, which can impact public market value or ability to fundraise (and if you play that out - it can even impact how much money you make based on how much your equity will be worth!)
Supporting Revenue Teams
Since Revenue ends up being such a significant factor, revenue teams are often compensated accordingly. As designers (engineers, PMs, etc) we're usually paid a base salary and equity compensation.
Our coworkers in revenue are instead paid a base salary with a bonus that depends on closing a certain amount of deals (often this is 50-100%+ of their base pay). Incentives matter! If I got paid per mockup, I'd probably make more even if I didn't think they were necessary. Given this, it's entirely unsurprising that revenue colleagues will ask for support from product teams to close a deal.
Not every request is equal though. While in an ideal world, revenue teams think this all through, it can be helpful for the product team to have context as well.
When you're asked to drop everything for a deal instead of long term work, it's worth thinking about:
When is the quarter going to end? Is it likely to meaningfully impact the quarter, and is it feasible given the remaining time? If there's one week left, the feature would take two weeks to build, and the customer need a demo to close, you probably can't make it.
How big is the deal vs. the average deal size (ACV) within the company? If your average deal is $100k and someone wants you to drop everything for a $1k customer who isn't likely to grow, it's probably not the best use of time.
Is this within the major customer profile?
How important is the logo of the customer? Logos can show expansion into new markets or provide valuable reference customers.
Who from sales or support is asking for the work? Last time you did this for them, did the deal close?
This is even more important when the request is being filtered through multiple teams. Being able to talk to the person directly responsible for the deal can help sort out exactly what they need (and might help you find a creative solution). By picking the projects that are higher value, you can increase the perceived value of design (or engineering) work, while maintaining the time to do the long term work that's already baked into future revenue assumptions.
Putting this all together, I hope having some financial context helps flip:
Everyone only cares about finance.
I keep getting asked to drop everything to hack together one deal.
To:
"Finance" or Valuation/revenue is a lagging indicator of everyone’s hard work, including mine. Chances are that our current valuation bakes in an assumption that we will continue to grow.
My coworkers don’t get paid as much if we don’t sign certain deals, so of course they'll ask me to help. I can use some basic knowledge about our fundamentals to help sort through theses requests.
Next week will be more focused on increasing the impact of designers in the organization. If you are a designer, or work with a designer, subscribe for some more effective ways to collaborate.
Other questions about finance or collaborating with revenue teams? Hit reply and I’m happy to do a follow up or quick fire set of questions.