
Enzo is the founder of [June](http://june.so/), a YC startup making it easy for product organizations to leverage user behaviour data. They’re a team of 6, with a heavy focus on engineering (everyone other than Enzo is an engineer!).

![Enzo](/a/post/a-single-goal-for-everyone/enzo.png)

Before we get going, note that document templates and other links mentioned in this post can be found in [this eesel folder](https://www.eesel.app/amogh-sarda/enzos-templates.2VSeZyaWkWqyHKgb6kZWAX).

## How do you set goals?

We started with OKRs at first and realised very quickly that they felt too heavy at our stage with only 1 team. We’ve now settled with something much simpler.

We set one goal for the entire company. We got this from our time at YC and gave it a cute word for ourselves - the “single goal”. It’s the translation of our top priority, and the singular focus for everyone. We set it each quarter, and we check in on our progress towards it every week.

We’ve had single goals to get 50 users that love us, get 100 new customers, get retention to X%, get to Z of MRR, and so on.

## Why do you think this works well?

Focus. It gives us a lot of focus, and that’s incredibly important when you’re early stage and there are _so_ many fires to catch up on. When you have so many disciplines in the company - success, marketing, engineering, product, you name it - and not as many people, it’s easy to get lost in intermediary goals and lose sight of the actual goals you want to achieve.

I believe it’s human nature to drift and do some work that feels good. This work most likely does not move the needle. You constantly need to challenge your team and ask them - “Is this the work that is most likely going to help us reach our goal?”.

Our single goal makes things simple. Whenever we plan to pick something - whether it’s product, customer success or whatever else, we ask if it helps us with the single goal. It’s simple, clear and everyone in the team has this top of mind. I believe the CEO's first role is to bring clarity, and this is key for that.

## Goals as guardrails to human nature, love that framing. How do you come up with this single goal?

So there are two parts to the single goal - the metric and the target.

For the metric, there’s no one clear path and coming up with it is a bit of an art. To be honest, a lot of it comes from our heads as founders. We chat with our investors or other founders, we take inspiration from companies we respect and so on.

One guideline we have is to be very selective about who we surround ourselves with. Who you listen to and who you’re inspired by has a huge impact on your decision. For example, 90% of SaaS businesses that are less than a year old like us don’t monetise, but we’re not sure this is the right way to go for us.

This ties in with another guideline we have. We generally push ourselves to the boundaries of where we are comfortable. We reflect on the hardest place we could reach right now, and well - that’s usually the goal we should have. For example, we felt comfortable getting happy users for June and it felt _uncomfortable_ thinking about getting them to pay us. And that’s why our upcoming single goal is to actively monetise.

For setting the right target, we follow the same techniques from OKRs. We aim to have something that’s “stretch” enough so we can feel pushed, but realistic enough that we don’t miss goals 3 times in a row. If you keep missing goals, it’s like having no goals, because it becomes this dream state that keeps eluding.

So for the target, the process roughly looks like this. We work backwards from our velocity to baseline, and then bump that by 20-30% as a way to add some “premium” to the goal and push the limits of our team.

## There seems to be a general theme around pushing an extra step with both your metric and target. Why do you think that’s important?

I think it’s important because it’s the goal of the founders to push the team, and if they don’t do that, no one else will.

Somewhat philosophically, I think that you reach the goals you set. I mean, you see that in life more generally. Some of my most successful friends from high school - the ones that reached their boldest dreams - had those dreams from the start, and it’s amazing to see that. I think there’s a strong connection between setting goals ambitiously and making that reality. Having the bold dream is what gives us a chance to reach it.

## I can imagine that a lot of people aspire to be ambitious but end up with wishful thinking. How do you avoid that?

We try to be realistic first. We’ve seen that being ambitious and not being able to reach the goal is actually demotivating. At our stage it’s a finger in the air of course, but there are some guidelines we can work backwards from to be sensible e.g. Paul Graham’s classic [post that exceptional startups grow 10% WoW](http://www.paulgraham.com/growth.html).

## How do you go about planning activities to reach this goal?

So after we set our single goal, we break that into a “cycle” goal we aim to hit in 6 weeks (something inspired by my time at Intercom). And on a week to week, each Friday afternoon, we have a planning where we think through activities to attack the cycle goal.

At the beginning of each weekly planning, we review our single goal - where do we stand, what worked, what hasn’t worked. This is awesome to have first because it’s important information to make better decisions for the activities we pick up.

For example, if last week Ferrucio picked up some article to help us grow but launching it didn’t really work out, if Ferrucio suggests doing it again, we have some previous learning to decide if it makes sense or not. Here’s a template of the planning document we use. It’s a kind of heavily modified variant to the one I used when at Intercom.

![Planning template](/a/post/a-single-goal-for-everyone/planning.png)
_You can find this in [this eesel folder](https://www.eesel.app/amogh-sarda/enzos-templates.2VSeZyaWkWqyHKgb6kZWAX)_

Alongside our activities, at the top of the document we have the single goal’s target, our current status and other things like who’s on call and who’s going to write our change log. We rotate those things.

## Hang on - you rotate writing change logs?

To keep a pulse on our customers and the problems they have, we wanted to make sure that engineers deeply connect with what they built, and even go as far as to communicate what they’ve built.

So rather than having one product marketer who does these things, each week one person writes our change log. This gives full ownership of work around not just building things but also communicating that. This was inspired by Linear and I’d [recommend reading their blog on this](https://medium.com/linear-app/startups-write-changelogs-c6a1d2ff4820).

## Are there any other artefacts you have that feed into goals and planning?

At a level higher than our single goal, we do have a vision and strategy.

The vision document is roughly our vision, mission and a one liner on what we want to be. We start broad there, and we then carefully challenge the purpose of every single word in the one liner. You need to be able to justify every single word.

This spins out into our strategy document which is what we refresh every quarter and cover where we want to go in the next 3-6 months: what we’re building, who we’re building for, what’s unique, where do we stand in the market etc. Here’s what that roughly looks like.

![Vision and Strategy template](/a/post/a-single-goal-for-everyone/vision.png)
_You can find this in [this eesel folder](https://www.eesel.app/amogh-sarda/enzos-templates.2VSeZyaWkWqyHKgb6kZWAX)._

This is what we eventually end up translating into a goal. We bring this up in board meetings and iterate based on the feedback. For these board meetings, we follow a standard format with our presentation, [inspired by Sequoia](https://www.sequoiacap.com/article/preparing-a-board-deck/#). Here’s a template of the board deck.

![Board deck template](/a/post/a-single-goal-for-everyone/boarddeck.png)
_You can find this in [this eesel folder](https://www.eesel.app/amogh-sarda/enzos-templates.2VSeZyaWkWqyHKgb6kZWAX)._

We think it’s best to follow standard templates with these things because having another format can be distracting away from the main things you want to focus on.

Once we align on that with the board, we mostly make a copy of this board meeting deck and present it to the team, which is the first time they see it. This is when we transition to our weekly rituals and more granular planning.

## Is there a reason you bring in the team only after you decide on the goal?

There’s a lot of upfront work that goes into this process, and we kind of protect the team and save their energy from all this. At the end of the day, it’s also more of an art than science, so if we wanted to spend hours more on this with the team and try to justify everything, I’m not sure if we’d be able to do it.

## Before we wrap up, how does June use June?

We dog food June like crazy.

The best part is that we often don’t even have to go to June thanks to our Slack integration. Every morning the team receives a report of our key metrics in a channel and everyone’s always on top of that.

I think product metrics generally need to be more embedded in our day to day, and that’s exactly what we want to do at June. We want to make it so easy and so accessible that analytics is a natural habit, and there’s no need for some rituals to check this or check that.


A single goal for everyone


JP is a Group Product Manager looking after the developer experience at [Contentful](https://www.contentful.com/), which is a popular Content Management System. Prior to Contentful, he was with Intercom where he built out their app marketplace.

![JP](/a/post/from-scribbles-to-strategy/jp.png)

Before we get going, note that document templates mentioned in this post can be found in **[this eesel folder](https://www.eesel.app/amogh-sarda/jps-templates.7xhLfJnzMw3GicKK5F5ynv)**.

## How do you set and track goals?

We use [15Five](https://www.15five.com/) which is a HR tool to track weekly goals and check in with managers.

![A demo image of 15Five](/a/post/from-scribbles-to-strategy/15five.png)

Each Friday, we do the following and this gets sent to our manager:

- Mark last week's goals as completed or not
- Answer “What went well”
- Answer "What’re your biggest challenge right now and how can I help”
- Give High fives (a way to thank someone)
- Do a pulse check in (1 to 5 overall score of how you feel)

This was something I was doing before with my manager already, and not as a company thing. We used to have a Google Doc for this instead. To avoid duplication we decided to move everything to 15Five.

![Goals template](/a/post/from-scribbles-to-strategy/goals.png)
_You can find this template in this [eesel folder](https://www.eesel.app/amogh-sarda/jps-templates.7xhLfJnzMw3GicKK5F5ynv)_

I find 15Five better because it feels more like a two way communication. I get a notification when my manager sees my update, my manager has to mark my goals as ‘reviewed’, and he can leave comments or emoji reactions. There’s more of a positive feedback loop and I can feel confident that my updates are being read. As a manager I get a pulse for how my team is doing and I can bring some of the topics in next 1-1 conversations.

## How do you track your daily todos?

On a day to day, I use [Bear](https://bear.app/) to track actions. I have one main list and group things like so:

- “Important” where I track things I’ll do this week
- “Next week” which is a catch all for everything else (I’ll get to this...one day)
- “Weekly updates” where I track things for my weekly update as they happen
- Groupings like “Small tasks”, “After holidays” that make sense based on the context

“Important” is mostly what I really keep up to date.

## Let’s talk strategy. How do you create a strategy for your product group?

All strategy starts with talking to customers. 

From there I roughly follow a high level structure. When starting with a blank document I start simple with scribbles and thoughts in bullet points. The goal is to share early and frequently so that you can collaborate with a few individuals in shaping ideas. 

Let’s talk through a specific example for a recent strategy doc. I first started with 10 bullet points and shared that. These bullet points were a rough strawman proposal to see how aligned I was with some of my closest peers. At a high level, it included an idea of what success looks like in the future, the big premise (“the challenge we need to overcome”) and what are a few directional goals. Strawman proposals are a great way to bring people together early. If you are far off, you’ll hear why quickly. 

Then I started getting more detailed and fleshed out the actual strategy document. Here is where I dug deeper into the data and validated some of the assumptions made. I also looked at comparing 2-3 scenarios we could take. The whole process is iterative, so as you have new findings you continue to seek feedback from your working group.  

At this point, I had an exhaustive document that covered what market we operate in, who our customers are, what are they trying to achieve, our challenges as a business and what we need to do to address this market opportunity. 

In this example, I also used the [3 Horizons Model from McKinsey](https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/enduring-ideas-the-three-horizons-of-growth) to split our investments in protecting our core business (Horizon 1), nurturing emerging business (Horizon 2) and genuinely creating new business (Horizon 3)

![McKinsey's 3 horizons](/a/post/from-scribbles-to-strategy/threeHorizons.png)
_McKinsey's 3 horizons_

From here, one of the last steps is to trim the content down to a concise, readable document. No more than 6 pages (excluding anything in the appendix). This is the rough structure I ended up with in this doc.

![Strategy and vision template](/a/post/from-scribbles-to-strategy/vision.png)
_You can find this template in this [eesel folder](https://www.eesel.app/amogh-sarda/jps-templates.7xhLfJnzMw3GicKK5F5ynv)_

That's only the start of course. Don’t forget the other half of the job is communicating that strategy and making sure you have the right incentives for individuals or teams to execute on it. 

## Scribbles to strategy sounds quite poetic. How do you approach hairy decisions in this process?

Guiding principles are a helpful tool for making decisions. If you run into a discussion of opinions, one way to resolve the conflict is by taking a step back and asking “What are we optimizing for?”. That will help you bring the conversation from the “what” down to the “how” and “why”. I’d even encourage defining principles early on a project, so that everyone is on the same page. 

This is why when writing an important document, I sometimes include 5-6 key “tenets” at the start to frame how we’re approaching our conclusions. We’ve found these really helpful for some of our toughest decisions (think: pricing). These principles are also helpful to build the narrative when communicating decisions to others in the company (in an all hands or so).

## That reminds me of [Atlassian’s decision sliders](https://www.atlassian.com/team-playbook/plays/trade-offs). On another note, what’s something you’ve worked on you’re really proud of?

One of the first projects I worked on at Contentful was to improve how we were getting insights from customer success, developer relations, and sales engineering. I wrote up a “What is a Customer Signal” document that explained to those teams the importance of writing in exact wording what the customer is asking for and explained how product teams need multiple signals to figure out insights (and root problems). We set up a Jira Service Desk portal for these teams to share specific customer signals with different product teams directly.

![Service Desk](/a/post/from-scribbles-to-strategy/servicedesk.png)

We report on these signals monthly (number of submissions, themes), and there has really been a broader culture that’s formed around this with lots of people consuming this page and sharing customer signal emojis on Slack for specific customer stories.

![Slack emoji](/a/post/from-scribbles-to-strategy/emoji.png)

## What’s something you’d like to improve about how you work?

A lot of my work is with documents and I worry that sometimes the trade off with “business case culture” is that you will gravitate towards things you can write up with good confidence and you can clearly measure. You won’t gravitate towards risky, more disruptive ideas that are harder to document with confidence. I’m curious to see how we can keep leaving space to take meaningful risks as a company. 


From scribbles to strategy


## Workarounds don't work, history repeats itself

The problem isn't hiding. It's painfully obvious and we've tried many things to solve it.

We've tried organising our work into Google Drive shared folders and Confluence spaces, but these are hard to maintain. Someone inevitably forgets to put that one doc in that one place, teams gradually loose faith in the system, and we all eventually fallback to pinging each other on Slack to find docs.

We've also tried standardising on tooling to _just_ use Notion or _just_ use Coda for everything. After all, if everything just happened in the one place, this wouldn't be a problem. Despite how flexible these tools have become, that's not possible in practice: designers still need Figma, sales still need Salesforce, recruiters still need Greenhouse. Moreover, it doesn't make sense to mandate that people use a specific tool if that's not how they want to work. It's ineffective, and teams often end up going rogue any way.

![The cycle of doc despair](/a/post/a-browser-made-for-work/the-cycle-of-doc-despair.png)
_There is no escape_

What's worst is that we're stuck repeating ourselves. As memory of an attempt at fixing this problem fades, we approach this problem yet again, with the same set of solutions we've already tried.

We're better than this.

## The epiphany

Our day 0 vision was to build a search across _all_ work apps. It's easy to extrapolate how this could be just like "Google Search but for your work". The approach also felt seemingly obvious - integrate with different apps using APIs.

We thought we _knew,_ but things got uneasy quickly. There are just _so many important work tools_ out there. Are we really going to build API integrations with everything? Hang on, this list is _always_ changing - it's not unusual to notice a colleague experimenting with a new tool any given month. If we really did want to search across _all_ work apps, we'd certainly be playing catch up with old and new APIs. You could argue that these were just the [schleps](http://www.paulgraham.com/schlep.html) we had to overcome, but it was amidst this uneasiness that we noticed what was right in front of us - the browser.

We work in the browser, but it isn't really made for that. Just look at the address bar. It's the primary way to access work but it gives a noisy mix of personal things, search suggestions, and work stuff.

![The address bar gives a noisy mix of personal things, search suggestions, work stuff](/a/post/a-browser-made-for-work/dashboard-search.png)

For all its flaws, the great thing about the browser is that it's built on a set of standards - the web standards. From HTTP and URLs to HTML and CSS, all apps we use in the browser follow the same predictable patterns: documents are accessed via URLs, content lives inside the HTML, there's a page title, there's a favicon, and so on.

This is actually a perfect replacement for APIs. There's no need to manually build integrations with every single app that people use for work (or will use in the future). We can just rely on existing universal web standards and be compatible with any app that you use in the browser - including apps that don't offer APIs (e.g. your internal company tools), or apps that don't exist yet (e.g. the next Product Hunt hit).

There's a catch though.

This only works with things that can be, and have been, opened in the browser. We can't help you access that Microsoft Word document on your hard drive, and we can't help you access that Google Doc that you've never opened before. This intuitively feels like a big drawback, but we've come to realise that it's not as critical as it sounds.

Firstly, accessing work seems to be more of a problem on the web and in the browser. URLs are _magical_. They've made it so easy to share work with colleagues and collaborate freely. All this has come at a cost however, as it has become quite overwhelming to navigate work. A product manager is linking you to Google Docs on Slack, an analyst is linking you to Tableau in an email, a designer is linking you to Figma on Zoom. We're sharing and receiving lots of links across lots of apps, all the time. In contrast, we're less likely to share files that live directly on our hard drives (probably because there's nothing like URLs to make sharing easy). This means that you receive less files on your hard drive, you feel less overwhelmed, and accessing work is not as painful.

Secondly, we usually just want to access things we've already accessed. This is very counter intuitive, but think about how often you actually want to access a document you've never accessed before. It's probably not that common, and when it does happen, you usually have to chat with someone to learn about (or confirm) the existence of the document anyway. e.g. "Do we have data on the last launch?" "Yes, I've created a Tableau dashboard for it, here's the link".

To sum up, searching for local files and accessing things you've never seen before, are both not that critical to solve for. These insights are the foundations for eesel.

## Now

We started by building a Chrome extension for ourselves and our immediate teammates. The extension was a basic filter over someone's browser history to extract links relevant for work (e.g. see all my Google Docs). It was dead simple, it worked with all our work apps, and there was no need to connect work accounts or give access to sensitive data. This alone was already delivering a lot of value.

So we kept improving the extension, and kept adding more teammates to the beta, all the way to our public launch on [Product Hunt in April 2020](https://www.producthunt.com/posts/eesel).

A year on after the launch, the before and after may not look different, but we've come a long way.

![eesel today](/a/post/a-browser-made-for-work/after.png)

The app is more customisable, faster, and now, you can even [take actions from eesel](https://www.loom.com/share/91b094cb468842f9a8c755789bfaf52b) (e.g. create new Github issues or join your next meeting). We've gone from tens of users in Intercom (read: friends) to thousands of users across great companies like Canva, Atlassian, Shopify, Monday.com, Gitlab and more.

Lots has stayed the same too. eesel is dead simple and _just_ works seconds after you install it.

<div class="imgStyled">

![eesel just works](/a/post/a-browser-made-for-work/usainbolt.gif)

</div>

eesel works with _anything_ in the browser. eesel is fully private and runs locally.

## Next

The cloud brought the first shift in collaboration. Having the most up to date view of files synced up in Dropbox was _magic._

The browser is bringing the next shift in collaboration. Web tech is more powerful (Figma is Adobe running in the browser), more universal (I hear JavaScript works on IE too) and makes collaboration easier (I don't need to download anything or worry about versions, I can just browse to the file like any other website).

![Evolution from email to cloud to browser](/a/post/a-browser-made-for-work/from-email-to-browser.png)
_Adapted from Kevin "Loops" Kwok's amazing blog on [Why Figma wins](https://kwokchain.com/2020/06/19/why-figma-wins/) ([@kevinakwok](https://twitter.com/kevinakwok))_

This means that word docs have shifted to Google Docs, Sketch designs have shifted to Figma, (basic) Excel has shifted to Google Sheets, VSCode has shifted to CodeSpaces. We're at an inflection point. More work will shift to the browser, and more collaboration will happen in the browser.

eesel will be there to enable that. We want to transform the browser into an operating system for work. We want teams to work seamlessly across their tools, no matter the tools.

We'll start by giving teams a shared source of truth. It will be a place to have all documents for a particular project, automatically organised (remember that you can't trust people to organise?). It's everything we wanted when at Atlassian, when at Intercom, when at Front, and I can't wait to show it to you in the coming months.

## Parting notes

eesel is our vehicle to have the most meaningful impact we can. There's lots that's wrong with the world, and there're lots of amazing people working on lots of pressing problems.

We believe that we're uniquely placed to enable others to do their job better, and that's how we can best impact the world. Even just enabling hundreds of people to do good work, better, is far more than what we could personally achieve ourselves (check out [operations and altruism](https://80000hours.org/articles/operations-management/)). We're excited to make eesel our life's work, and we're excited to help you do your life's work.


A browser made for work

## Before you decide to raise

### Build infectious conviction

If you're waiting for funding before you quit, if you're waiting to find a cofounder before you talk to customers or build a prototype, if you're waiting for _something_ to do _anything_ - you should understand what’s stopping you from moving. The reasons why you feel shaky are also the reasons why someone else won't invest. You need to strongly believe before you can convince others to believe. There are two caveats to make.

Don't get stuck “waiting for the right idea” you believe in. Ideas don’t just automatically latch on to you, and conviction doesn’t build incidentally. You need to put in time and effort to build on rough thoughts, explicitly ask the hard questions, and in this process, convince yourself of an opportunity.

Don't mistake this to mean that you need to answer _all_ questions or convince everyone that this _will_ work. In fact, there are many people I respect who just don't get eesel, and we have lots of unknowns ourselves. You'll need some resilience in the face of skepticism. Just check out the comments [Coinbase](https://news.ycombinator.com/item?id=3754664) or [Dropbox](https://news.ycombinator.com/item?id=8863) got when getting started.

### Get a plan B

![Raising gets easier if you have a Plan B](/a/post/how-to-raise-for-the-first-time/plan-b.png)

You're most in control of the whole raising process when there's an alternative to raising you're comfortable with. Things felt starkly different for us when we had a plan B - world views shift from one of desperation to one of agency, and that shift bleeds into everything about this process.

Of course, sometimes, there really is no option and you absolutely need upfront capital. I'd just urge you to reflect on this. If your idea is really so exciting and you’re bursting to get started, it should take a lot to stop you completely. Maybe a plan B is to start monetising earlier than expected? Or work part time as a freelancer and continue working on your idea on the side?

## Before you start reaching out

### Get in the right mental state to face lots of rejection

Some chats go really well. You feel a real connection, you feel like you're very aligned, you feel like they could bring value, and yet, you still end up being rejected. These are the rejections that hurt the most. Heed whatever learnings you can and keep moving - it's not the end to that relationship (there are many tales of folks saying no to say yes for a later round) and it certainly doesn't mean the end of your company. Even the best investors and the best companies can just not click e.g. some [great](https://www.bvp.com/anti-portfolio) [investors](https://avc.com/2011/03/airbnb/) passed on Airbnb. Keep your's and the team's spirits high, as no one else will do that for you.

### Index on market trends for valuation and round size

It's natural to approach questions on valuation and round size by looking at the:

- intrinsic value of the business today
- amount needed to [reach a milestone](https://cdixon.org/2009/12/28/whats-the-right-amount-of-seed-money-to-raise), plus fudge factor

However, when there’s no revenue to show for and little growth, knowing your intrinsic worth or _how much money you need to get to product market fit_ is full of unknowns.

There are other less obvious factors that are easier to figure out:

- valuations going in the market for similar companies
- dilution you are okay with
- ownership investors expect

In other words, look at how much you need, but index on how much the market will give. This implies you raise as much as you can for a dilution you're okay with. Of course, [contrarian takes](https://twitter.com/_shahedk/status/1374374780065869831) exist, and there's a point to be made that raising lesser brings constraints, which brings focus.

### Time the narrative

![When to raise](/a/post/how-to-raise-for-the-first-time/when-to-raise.png)

In theory, you can raise at any stage - before revenue, before product market fit, before the product is released, before you start building anything. However, wherever you are in the growth of your company, you need to convey a convincing vision about where you want to go next, and explain that money is pretty much the main bottleneck. For example, it’s probably not a good idea to raise right _after_ a big launch, while you’re yet to clearly know what's next. So figure out the next milestone with truthful detail, and frame the funds as the main bottleneck.

### Break down a large round into smaller chunks

It’s totally fine to increase your round size because you’ve had too much interest, rather than vice versa. You’re better off starting with a round size that’s a bit more modest and increasing that over time. e.g. if you're looking to raise $2M, start by first closing $500k and so on.

## When you reach out

### Bring tight structure

The steps needed to find product market fit are nebulous, and you need to be innovative about your path. In contrast, at least the first steps to raising have almost no ambiguity, and you don't need to get too creative. Make sure you transition away from a product mindset (where paths are unknown) and treat raising like sales.

- Have a timeline: Know when you’ll iterate on the pitch, when you'll start reaching out, and so on.
- Set up a pipeline: Use a simple Kanban board, [visible.vc](https://visible.vc/) or even a CRM to keep track of all the potential investors you want to contact and where they are in your process (To Contact > Contacted > Call Scheduled and so on). We used Notion and it worked fine.
- Create territory: You can source target investors from [OpenVC](https://www.openvc.app/), [Shai Goldman's list](https://docs.google.com/spreadsheets/d/1ebGZ6-ivf_3woBGC4Kz_3217DhjGsefoRu_5iP3nuFQ/edit#gid=0), AngelList, [Nfx Signal](https://signal.nfx.com/), [VClist](https://www.vclist.online/) or even Crunchbase by looking at investors of companies you admire or investors of companies that are kind of similar. For each of these, evaluate how you can get warm intros.

Note: In theory, you don't need an explicit round with a specific deadline, and can actually raise on a rolling basis where you progressively add investors. I can't speak to how well that works in practice but even if you proceed this way, having some structure will probably help.

### Reach out _mostly_ in parallel

If you approach investors one by one, fundraising will just drag on for way too long, and worse, you'll miss out on building buzz with the round. You ideally want to have calls back to back, packed in a few weeks, and progress folks through the stages together.

Amidst the back to back, you'll want to leave some space to iterate on your pitch. You'll also want to stagger some folks. In particular, it's a good idea to become "a lean mean pitching machine" and already have momentum with the round before reaching out to your most coveted investors. Likewise, some angels aren't comfortable being the first money in, and are best approached when you already have most of the round closed (we made this mistake ourselves).

### Share a Loom walk through of your pitch

I came across this tweet from Harry Stebbings and it made total sense.

<p>
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Single easiest way to increase odds of raising VC funding in remote fundraising world:<br><br>Record 10-minute <a href="https://twitter.com/loom?ref_src=twsrc%5Etfw">@loom</a> walking through the deck &amp; answering FAQs. <br><br>Ensures all partners at X fund are in the loop. <br><br>Scales your time as Founder significantly. <br><br>Separates you from the pack!</p>&mdash; Harry Stebbings (@HarryStebbings) <a href="https://twitter.com/HarryStebbings/status/1289685815082196992?ref_src=twsrc%5Etfw">August 1, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</p>

In theory, this could be a great way for everyone to skip past the first chat. So after the initial back and forth, when a call would be suggested, we'd link to a recorded run through. Perhaps 10mins is too long, or folks just aren't used to this yet, but most didn't watch the video. When folks did watch it however, the interactions felt tangibly better. This practice does seem to [be](https://twitter.com/myfriendjanine/status/1296137972325273610) [increasingly](https://www.loom.com/blog/remote-pitch-deck-best-practices) [encouraged](https://twitter.com/VullinghsJ/status/1295878656078704640) so I think it's worth a go.

### Focus on warm intros much more than cold outreach

75% of our warm intros led to a call, while only 18% of cold outreach led to a call. The general addage is that if you craft cold with care, it'll work.

<p>
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Sending 100 copy-pasted cold emails in one hour: 1% conversion rate.<br><br>Sending 10 unique cold emails in one hour: 80% conversion rate. <br><br>Plus you’ll have practiced your writing skills, and done more research on the people you’re trying to help.</p>&mdash; Sahil (@shl) <a href="https://twitter.com/shl/status/1221161714026078208?ref_src=twsrc%5Etfw">January 25, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</p>

There's still truth to this, but it really needs to be highlighted that cold, even if personalised, is _no where as good_ as warm. Here's what our cold outreach looked like:



<div class="imgStyled">

![Cold Email](/a/post/how-to-raise-for-the-first-time/email.png)

</div>



We'd personalise the copy further and add a personalised GIF.

<div class="imgStyled">

![Murat](/a/post/how-to-raise-for-the-first-time/murat.gif)

</div>

No matter the personalisation, and the fact that this is one profession where cold emails are encouraged, cold outreach doesn't work that well. You're often just ignored, and even if you end up talking, the dynamic is not as good as conversations starting warm.

In retrospect, I'd focus most of my energy on getting warm intros one way or another. **Do cold only for contacts you _really_ _really_ want to chat with but _genuinely_ have no way to a warm intro.** Ideally, they'll also be folks who actively seek cold intros e.g. [see this list](https://twitter.com/paulbz/status/1271416618468413446).

All this depends on your network of course but, for what it's worth, I was very surprised by how many amazing people I was just 1 degree away from. Go to LinkedIn and see mutual connections. You may be surprised too.

## When you're actively talking to investors

### Why + Why _now_ = Action

To prompt action, you need to answer not just "Why invest", but also "Why invest _now_". Unless there're explicit constraints that create a need to act, delaying the decision to invest is actually the most rational course of action for any investor.  
Why wouldn’t I just say "maybe", wait and see what you get up to over the next weeks, and keep delaying the decision? If you start getting traction, then great - I can jump in as a believer. If you don’t, then great - I haven’t missed anything.  
Likewise, as a founder, you’ll also want to delay decisions of your own e.g. you’ll want to keep refining your pitch before reaching out to a high profile investor ("you only get one chance to make a first impression" you'll tell yourself).

This is why you need to create constraints to keep both investors and yourself moving. For investors, it could be the sense that the round will close at a certain date, or that someone else could fill the round, or that you could have a big launch which could significantly change valuation, and so on. For yourself, it could be the sense that competition is moving fast, there’s meaningful product work that’s being delayed and so on.

### Don't let the 'cold' distract you

Don’t spend your energy on trying to convince ‘cold’ and ‘lukewarm’ that drags on - don't send that 2nd follow up email to someone who never replied, don't burn time having lots of meetings with the same folks. Acknowledge that it's just unlikely that someone moving slow and showing less interest at first will have a total swing in another direction.

Of course, there's some nuance to keep in mind - the best folks by definition have a lot prying for their time, and putting in effort when no one else does, stands out. Treat your time and energy as finite, and use your judgement.

## When you're in the final stretch

### Embrace the unknowns of the final crunch

While you can start fundraising in a structured way, when things are in flight, the best you can do is keep an open mind and embrace the rush. You could end up with a cap table you couldn't have expected. e.g. we closed with K Fund who we got an intro to from an acquaintance, totally out of the blue, only in the last minutes.

### Don't overthink dilution

You've been told this already, but I'll reiterate it because it's hard to truly digest. You naturally want to feel like "you got the better deal" when playing the valuation game against investors or other startups.

In this [great talk](https://genius.com/Peter-thiel-lecture-5-business-strategy-and-monopoly-theory-annotated), Peter Thiel mentions that competition makes you better at whatever it is that you're competing at. It's critical to remember that you're not competing to get the best valuation. You're competing to survive, and surviving when most startups fail is what winning will be. I still struggle with this personally, but [how PG put it](http://www.paulgraham.com/fr.html) has especially stuck - Airbnb raised their seed at a $2.6m valuation, so if valuation is what matters, you're already better than Airbnb.

There's of course a balance, and you don't want to be the next Airbnb but own nothing when it comes to liquidation. However, 1 or 2 more percents of dilution in your first rounds could be worth it to ensure survival ([read this for more nuance](https://www.ycombinator.com/library/4o-dilution)).

### Stay standard with the legal stuff

Staying standard makes everything smooth.

- We used [Stripe Atlas](https://stripe.com/atlas) to incorporate eesel. [Clerky](https://www.clerky.com/) is great too, though in our case (as foreign founders) there is one form (called the EIN) they wouldn't file.
- We used [Safe](https://www.ycombinator.com/documents/) (Simple Agreement for Future Equity) which is essentially a very simple and standard template for all the paperwork needed to sign terms with investors.
- We use [Mercury](http://mercury.com/) for our bank and it's been amazing. They don't charge a monthly fee and the user experience is pretty slick.

Free up your time to focus on the important stuff, and don't add friction for an investor already jumping hurdles to build conviction.

## Carve your own path

There is no one way to do this, and there is no way you will be able to account for all the variables. We've seen counter examples for a few common sayings:

- People suggest you [don't get an intro from someone who rejected you because it's an “anti-recommendation”](http://www.paulgraham.com/fr.html#f7n). However, [Qwilr got rejected by AirTree and got an intro to P9](https://medium.com/airtree-venture/airtreeqwilrseriesa-155c92beec56) who then ended up investing.
- People suggest you [don't raise with multi stage funds for seed](https://cdixon.org/2012/04/02/revisited-big-vcs-investing-in-seed-rounds) as they aren't incentivised to price up the next round and there is “signalling risk” if they don’t join. However, Loom had a [multi stage firm in their seed round](https://www.thetwentyminutevc.com/joethomas/).
- People suggest you [only talk to partners as associates don’t have authority](http://www.paulgraham.com/fr.html#f5n). However, Mona [closed their seed round](https://www.crunchbase.com/funding_round/quorum-92a9-seed--3fd238cf) with an associate championing them.

You could go mental trying to ensure every step is optimal. Seek to learn from everyone and everything - and at the end of the day - trust your judgement and carve your own path. You got this!

## Some reads

Here're some reads I'm grateful for.

- YC's [guide to seed](https://www.ycombinator.com/library/4A-a-guide-to-seed-fundraising), [Safe primer doc](https://www.ycombinator.com/assets/ycdc/Primer%20for%20post-money%20safe%20v1.1-b12b459ccdcf1ff659f1eabb4c1969f2e4ca6a063d43bf2fbed76d1d376ee1a3.pdf) and [video on priced rounds](https://www.youtube.com/watch?v=Dk6JNTDec9I)
- PG's [guide to fundraising](http://www.paulgraham.com/fr.html)
- [Mark Suster on pro rata](https://bothsidesofthetable.com/what-all-entrepreneurs-need-to-know-about-prorata-rights-e5883fd21f80) and just about everything
- [Christoph Janz on benchmarks](https://medium.com/point-nine-news/what-does-it-take-to-raise-capital-in-saas-in-2020-8fc96d4ed18a) and just about everything
- [Fred Wilson on Safes](https://avc.com/2019/05/unsafe-notes/) (notable counter points) and just about everything
- [Holloway's guide to raising](https://www.holloway.com/g/venture-capital/preview)
- [NFX's guide to raising](https://www.nfx.com/post/the-non-obvious-guide-to-fundraising/)

How to raise for the first time


When it comes to learning something new, it's not unusual that concepts learnt in a 101 class are especially simplified takes on the world. When we get a glimpse of real world nuance, we realise pretty quickly that things aren't that black and white. Let's push past the 101 and get a more nuanced take on some standard product management concepts.

## 1. Don't use "ship to learn" as a cover for laziness

![Don't use ship to learn as a cover for laziness](/a/post/pm102-the-classic-lies-in-product-management/dont-use-ship-to-learn-as-a-cover-for-laziness.png)

It's too easy to deflect thinking about how people will discover a feature, how they'll use it, if they'll find it valuable, and so on, by saying "let's ship and see what happens". Be careful that you're not just avoiding work.

There are indeed things you can't anticipate and there's some truth to "ship to learn". However, thinking is cheaper and faster than building, and helps ensure you make and measure the right things. You can go further in thought than you realise and you shouldn't underestimate that. I mean, "thought experiments" were enough for [Einstein to figure out relativity](https://en.wikipedia.org/wiki/Einstein%27s_thought_experiments).

## 2. It's okay to start with the solution

![It's okay to start with the solution](/a/post/pm102-the-classic-lies-in-product-management/its-ok-to-start-with-the-solution.png)

It's common knowledge that you should always start from problems. However, sometimes it makes sense to start from a naive solution, specific tech, your strategy and so on. These are the "wouldn't it be cool if..." ideas.

Don't feel like you have to abruptly cut discussions and make sure you start from "first principles" with a problem. Give space to customers, colleagues and yourself to bounce ideas without judgement, because this can take you places linear thinking from problem to solution can't. For example, Alexa wasn't the result of some problem looking for a solution, but the result of an engineer playing around with some cool tech - a voice control speaker.

You'll need to eventually figure out if your solution is something people want, but it's okay to let your mind wander for a bit.

## 3. Don't ship if you're embarrassed

![Don't ship if you're embarrassed](/a/post/pm102-the-classic-lies-in-product-management/dont-ship-if-you-are-embarrassed.png)

There are classic adages to start with a "cupcake" and "launch fast" because "if you're not embarrassed, you've launched too late".

While Reid Hoffman [has clarified the nuances of his initial quote](https://www.linkedin.com/pulse/arent-any-typos-essay-we-launched-too-late-reid-hoffman/), I've seen this phrase used countless times to justify _bad work_. You ship something bad citing "it's just a cupcake", things inevitably don't work, and then you say that's okay because "it's not a failure but a learning". Rinse and repeat.

Just scoping down doesn't make it a cupcake. It still needs to be edible, and dare I say, taste good. You need to have confidence that _someone_ will use what you make and extract _some_ value. It may not do much, but it _should_ do something important well. The perfectionist in you is allowed to be uneasy that it's not a wedding cake, but there shouldn't be any reason to be embarrassed.

## 4. Stay grounded on the problem when prioritising

![When prioritising, stay grounded](/a/post/pm102-the-classic-lies-in-product-management/when-prioritising-stay-grounded.png)

Prioritisation is hard and fuzzy, and we try bring more structure by creating abstract concepts - a strategic direction, competitor landscape, "reach" or "impact" scores for "features", and so on.

Be careful you don't get too caught up in these abstract worlds. It can leave you stuck on the wrong details (e.g. "is it a 0.5 or a 1 for reach?"), or worse, with wishful thinking about how the world works (e.g. building a "strategic fit" feature to "help improve virality", only to realise it doesn't solve a real problem).

Instead of "features" or "strategic fit for vision", the most _real_ and _concrete_ concepts are problems people have. We should stay grounded on that above all. Establish pressing problems people have foremost, and filter that down for things that match your strategy and are a reasonable effort to tackle.

## 5. Your product is not that important

![Your product isn't that important](/a/post/pm102-the-classic-lies-in-product-management/your-product-isnt-that-important.png)

You spend 8 hours a day, 5 days a week on your product. It's the centre of your (working) world, and from this vantage point, you can fall victim to the [focusing illusion](https://fs.blog/2015/09/focusing-illusions/) and form a false sense of how important all this stuff is.

Most people don't care. They have so many things they need to do, and so many things asking for their attention. Your product is just one other thing they use to get what they want.

When we misunderstand this, we do stuff that don't make sense. We expect people will readily switch over to our product, but they have existing habits they're stuck with. We expect they'll invite their teammates, but they fear sticking their neck out. We expect they want an in product tour of what's new, but they just want to finish a specific task and move on.

Of course, all this will vary based on the customer and the nature of your product, but chances are, you're overvaluing your place in your customer's world. Understand the broader workflow, habits, fears, needs and get a true sense of your place in this world.

## 6. Research isn't always the answer

![Research isn't always the answer](/a/post/pm102-the-classic-lies-in-product-management/research-isnt-always-the-answer.png)

Product work is a series of educated guesses with some degree of uncertainty. It's too easy to deflect decisions with "let's do more research" or "let's look at more data" but that's not _always_ the right answer. The effort you put in to collecting information to make a decision should be a function of how important the decision is and how reversible it is.

Pause and honestly reflect if more research is needed to make a reasonable decision, and don't needlessly stray from risk. There will always be inherent uncertainty with a decision, and you need to weigh the importance and reversibility of the decision (i.e. risk) against the costs of more research.

## 7. Don't rush to say no

![Don't rush to say no](/a/post/pm102-the-classic-lies-in-product-management/dont-rush-to-say-no.png)

The classic adage is to say "No" a lot, because that's how you bring focus. While this is important, I think we tend to misplay it.

When a new idea comes, it doesn't feel fair to default to "No". We have so much inertia to keep things as they are, and a new idea is rarely going to be formed enough to have immediate sway. Instead, it feels fairer to first build with a "Yes" and find all the ways the idea _can_ work rather than all the ways it can't.

Unlike a quick deflection with "No", "Yes" requires empathy and active listening which makes it _much_ harder to do. However, this is how we empower everyone to influence product, and help shape crazy ideas to be crazy good ideas.

This doesn't mean you should spend hours on every trickle of thought or _do it all_. Use your judgement, of course, but challenge yourself to first say "Yes" and support a new idea - even if just for a little bit.

## 8. Strong opinions, weakly held ≠ Loud opinions, always changing

![Strong opinions, weakly held](/a/post/pm102-the-classic-lies-in-product-management/strong-opinions-weakly-held.png)

The initial premise makes sense - form "strong opinions" to help decisions progress, and have the flexibility to change these views. When taken to an extreme, however, this can become an escape hatch to express loud views with no basis, and flip flop at the sight of any new information. This makes it hard to make fast, faithful decisions as there's no clear sense of what you should and shouldn't index on. We pollute _what we really know_ with baseless judgements and oscillating opinions.

It's [already so easy to fool ourselves](https://speakola.com/grad/richard-feynman-caltech-1974), and we shouldn't make that easier. Form truthful opinions with a fair amount of conviction. If you don't have much basis, express opinions with a clear sense of uncertainty. If you have strong rationale, form strong opinions that you hold tight, until new information _rightfully_ changes your view.

## 9. Don't add more product as a default

![Don't add more product by default](/a/post/pm102-the-classic-lies-in-product-management/dont-add-more-product-by-default.png)

Our natural instinct as product people is to solve things with _more_ product. [Kind of how entropy always increases over time](https://jamesclear.com/entropy), there’s a natural flow in product to add more features, permissions, templates, automations and so on. We risk being stuck, always _one_ big release behind resolving adoption for the _entire_ product. Andrew Chen has [a great take](https://andrewchen.com/the-next-feature-fallacy-the-fallacy-that-the-next-new-feature-will-suddenly-make-people-use-your-product/) on this.

<p>
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">The Next Feature Fallacy: the fallacy that the next feature you add will suddenly make people want to use the entire product.</p>&mdash; Joshua Porter (@bokardo) <a href="https://twitter.com/bokardo/status/598959253454336001?ref_src=twsrc%5Etfw">May 14, 2015</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</p>

Pause and get honest with yourself. Good product is a series of good decisions, and it's rare to have one _more_ thing fix it all. More over, it's better to do less, better. Before you add more, deeply understand why things already there aren't working.

## Wrapping up

It's hopefully clear by now that product requires a lot of nuance. Even the most common place product concepts require some level of good judgement with application. The good news is that only you are best placed to make this judgement.


PM102: The classic lies in product management

Startups start "[default dead](http://paulgraham.com/aord.html)", and need to change something to become profitable and "default alive" before money runs out. To navigate this "path to default alive", they need to know where they are today, where they need to be, what they're doing, the change that will have, and how they're progressing.

There's a lot there, and [**we track all this for eesel in one place**](https://docs.google.com/spreadsheets/d/1qfyAp_daC6FXwg7pL7EO23C8mV03Ey773m-WA78va3g/edit?usp=sharing).

![Template overview](/a/post/track-your-path-to-default-alive/template.png)

We think others will find this template handy too, so here's a quick guide on how to use it.



## 1. Lay out your milestones

List out all milestones that impact core metrics in some way. In practice, this should be most of what you do. I mean, if it's not impacting your metrics, why are you doing it?

![Lay out your actitivities](/a/post/track-your-path-to-default-alive/activities.png)

You can split these milestones by activities like product, marketing and so on.

## 2. Record actuals and targets

List out your core metrics and their breakdowns. Actuals are the state of the world today. Targets are estimates of how you expect things to change. It's really important to capture things in a holistic way, and we've covered [how to use growth accounting to do this before](https://www.eesel.app/blog/your-metrics-belong-in-a-system).

![Actuals and Targets](/a/post/track-your-path-to-default-alive/actuals-and-target.png)

Activities you're doing should make metrics move, and that's highlighted in yellow. For example, you can see improvements we expect on launch of Feature X in May.

![Yellow bump](/a/post/track-your-path-to-default-alive/featureX.png)

We hardcode these bumps as "Inputs". For example, you can see that we expect Feature X's launch to improve the New and Churn rate for Active users.
![Inputs](/a/post/track-your-path-to-default-alive/input.png)

We're no expert on creating estimates, but a tactic we use is to isolate the impact of the activity with step by step reasoning. Walk through the steps for how many people will get exposed to the feature, how many will try it, how many will really engage, how many will continue using it, and so on.

For example, let's look at the impact of Feature X on Net Churn. Our research and intuition suggests that we expect for every 10 people currently leaving, 9 people will be exposed to the feature, 7 will try it, and we think 3 will be convinced to stay. This means that we expect a 30% improvement in Churn, and that brings it down from 15% to 10%.

There are other ways of doing this. This is a good read by Sequoia on [top down or bottom up goal setting](https://www.sequoiacap.com/article/defining-product-success-metrics-and-goals). Use whatever is most sensible for you, and seek to learn and improve on how you forecast with time.

## 3. Visualise actuals and targets

Take actuals and targets for core metrics, and plot them. You'll be able to see the path you are on today and the path you need to be on. From MAU to MRR to breakeven, you can do this for a few things and we suggest focusing on 2-3 charts for simplicity.

![Lay out your actitivities](/a/post/track-your-path-to-default-alive/mau.png)

As eesel is currently "default dead", we like to call this target trajectory our "path to default alive".

## 4. Do check ins at a regular cadence

It's obvious that all this is only useful if you actually look at the numbers regularly. The hard part is getting in the habit of doing that.

We've found [habit stacking](https://jamesclear.com/habit-stacking) to work well here. For eesel, we coupled metric checkins with planning. We already had a habit to plan our goals, and we just made checking into metrics a part of this habit.

![Monthly metrics](/a/post/track-your-path-to-default-alive/goals.png)

We plan at a weekly level, where we look at a subset of weekly metrics. We plan at a monthly level, where alongside our goals, we look at our path to default alive. Metric checkins are a part of our planning template, and feed into what we're going to do next. Doing these regular check ins is what gives us an opportunity to learn and course correct.

## 5. Beware of the plan's naivety

The template we're sharing is very simple, and you need to apply your judgement. Be honest about the uncertainty attached, and [don't forget that the map is not the territory](https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation). Don't believe that you can reasonably grow at a high compound growth rate for extended periods. Don't believe that you can meaningfully bump your metrics with the [launch of a feature, right away](https://andrewchen.com/the-next-feature-fallacy-the-fallacy-that-the-next-new-feature-will-suddenly-make-people-use-your-product/) (ah, if only).

Reality is of course nuanced. Feel free to capture these nuances as it makes sense, but remember that there's a trade off, and you don't want to make things too wieldy to digest.

## Wrapping up

That's it! You've got a path, and now you _just_ need to hit those targets. Easy, right? :)

Treat this template as a starting point. We're no expert on all this and we're still making things up as we go along. For example, we're still figuring out how to bring more focus with the plan (it's easy for there to be a _lot_ to take in), and how to bring in cohort retention (which is of course key at an early stage).

Feel free to extend the template as it makes sense, and do let us know if you have ideas on how to improve it.

## Some reads

A few reads were crucial to our understanding of all this and we are grateful for them.

- Christoph Janz's [dashboard](http://christophjanz.blogspot.com/2013/12/a-kpi-dashboard-for-early-stage-saas.html) which is more revenue oriented
- David Skok's (timeless) take on [SaaS metrics](https://www.forentrepreneurs.com/saas-metrics-2/) and his [dashboard](https://www.forentrepreneurs.com/wp-content/uploads/2020/04/SaaS-Metrics-4-16-2020.xlsx)
- YC's talk on [startup metrics](https://www.ycombinator.com/library/6k-growth-for-startups) and this [growth calculator](http://growth.tlb.org/)

Thanks to Jo Niec, Rahul Reddy, Louis Ryan, Helene Reydet for helping with our template and this post.

Track your path to default alive


Being good at SQL, data visualisation and extracting insights is like being good at navigating with a map. The thing is, someone needs to make the map in the first place - a system of metrics - and that's a totally different skill. It's something you rarely get exposed to because in established companies, a system is usually already in place. It also doesn't help that there's [lots of](https://future.a16z.com/north-star-metrics/) [content](https://www.sequoiacap.com/article/defining-product-success-metrics-and-goals) on defining some north star, but not so much on defining a group of metrics to capture your business as a whole.

So when you're a newbie - who isn't an analyst - it can be disorienting to make sense of it all.

## Problems with a naive approach

I'd wager that most folks start naively. You care about user or revenue growth, and perhaps knowing if you are [default alive or dead](http://paulgraham.com/aord.html). That's a good start, but these are [output metrics](https://www.reforge.com/blog/north-star-metric-growth). They aren't actionable on their own and you need more granularity to investigate why growth is the way it is.

So you start looking at things that are interesting or feel _obviously_ important - daily active, daily uninstalls, monthly active, retention curves, power user curves and so on. Not too far in, things get messy.

### 1. Premature focus creates blindspots

It's dangerous to bring tight focus to a small number of metrics, before you have full view of the business. You could be stuck with implicit assumptions, but have no way of challenging them. There could be a grave problem or big opportunity outside your observed view.

A cautionary tale about this is covered by Casey Winters in [this post](https://caseyaccidental.com/one-key-metric-victim). Both GrubHub and Seamless do food delivery. Seamless equated revenue for Gross Merchandise Volume (order size and number of orders), while GrubHub viewed revenue as GMV multiplied by the average commission. A subtle difference to include "commission" in the system drastically changed how the two companies optimised for revenue. For example, while Seamless search results sorted restaurants in alphabetical order, GrubHub sorted them in order of commission earned. When the two businesses eventually merged, Casey recalls that "this was one of the first changes that was made to the Seamless model as it would drastically increase revenue...even though it didn’t affect GMV".

Similarly, say you [read this classic Superhuman post](https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit) and decide to track retention for a tight cohort of users. Even if you decide to ignore all other users, you need a system in place that acknowledges these ignored users and spells out your assumptions explicitly. Your assumptions to bring focus could be wrong, there could be some hidden problem (e.g. you need to drastically improve the quality of acquisition), things could change with time (e.g. your ignored users become a good fit) and so on.

### 2. It's confusing to have lots of metrics

If you just come up with the most intuitive set of metrics for each particular context, things can get confusing. You can end up with many similar things measured slightly differently, and no clear sense of how things relate. For example, you could be looking at churn rate and Month on Month engagement for one feature, but Week 4 retention and Week on Week engagement for another.

Without the guidance of a global system, local definitions will keep piling and complexity will compound. For example, fundraising will introduce concepts like burn and cash balance, which could be tracked differently to revenue.

### 3. Non obvious definitions introduce mental burden

While some arbitrary definitions are unavoidable, each time you do this, you introduce some recall for your team and future you, and this can be quite disruptive. Things can make total sense in context, but not when you zoom out or come back later.

For instance, in eesel, "disabled" users were users not seen for 30 days. Even if we knew this by heart, we would still have some friction when looking at a visualisation of "daily disabled" - "ah this is a laggy metric", "ah it's 30 days not 28 days".

## Build a system of metrics

It's hopefully clear by now that before diving into numbers, you need to step back and come up with a holistic system. You need to map your terrain, before you figure out your path.

### Step 1. Understand Growth Accounting

A metric moves from one point to another, over a period of time, because some things _add_ to it, and some things _subtract_ from it. There is no other reason for it to move. Growth Accounting is about breaking down the different components that cause a move.

![Understand Growth Accounting](/a/post/your-metrics-belong-in-a-system/growth-accounting.png)

In that vein, the growth rate for a metric is the following.

![Growth rate](/a/post/your-metrics-belong-in-a-system/growth-rate.png)

Growth Accounting is a simple and obvious concept, but _everything_ comes back to it. The magic is that you can apply it to any metric - whether it's active users, engaged users, burn, revenue.

### Step 2. Figure out your core metrics

Establish a few core metrics for which you want an exhaustive breakdown of any movement. You'll want to have at least one thing that closely captures the value your business provides. This is usually more actionable and leads any lagging changes in revenue or retention. e.g. eesel has "engaged users" which are users that access a document or use commands.

### Step 3. Figure out a cadence

Establish if you're defining things at a daily, monthly, quarterly level and so on. One heuristic [covered in this YC talk](https://www.ycombinator.com/library/6k-growth-for-startups) is to look at the frequency at which someone gets value. e.g. Airbnb measure retention at a yearly level because that's how often they expect people to make bookings.

There is no one formula, and you should use your good judgement. For instance, we think eesel's value is derived every week, but we define metrics at a monthly level because of limitations with our churn definition (which only makes sense at a monthly level).

### Step 4. Breakdown what adds or subtracts

You can be as specific or abstract as it makes sense. The key thing is to explicitly introduce language to discuss the different components that move a metric. Let's look at some standard SaaS examples.

For monthly cash balance, there's:

- Revenue: $ coming in
- Burn: $ leaving

![Cash balance example](/a/post/your-metrics-belong-in-a-system/cash.png)

For monthly active users, there's:

- New: Users that showed up for the first time this month and are Active
- Churn: Users that were Active in the past month but not this month
- Resurrected: Users that joined before, weren't active in the past month, but are now active

![Monthly active users examples](/a/post/your-metrics-belong-in-a-system/active-users.png)

For monthly recurring revenue (MRR), there's:

- New: $ that is fresh from new users who started paying this month
- Churn: $ that we were expecting to get at the start of the month but didn't, because users churned this month
- Resurrected: $ from users who had churned before but then started paying again
- Contraction: $ from users who changed plans and are paying lesser this month than before
- Expansion: $ from users who changed plans and are paying more this month than before

![MRR example](/a/post/your-metrics-belong-in-a-system/mrr.png)

You can establish growth rates for each by applying the formula mentioned above.

### Step 5. Introduce metrics to make connections

Establish how different metrics relate and introduce any concepts needed to make connections. For instance, in eesel, we introduced metrics to make connections between active, engaged, and paid users.

![How metrics relate](/a/post/your-metrics-belong-in-a-system/connecting.png)

If each core metric is like a currency, these are like your conversion rates.

### Step 6. Fill in any gaps

At this point, there could still be some parts of the business that aren't captured, and you should introduce concepts to cover this ground at a high level. For example, in eesel, "New active users" isn't the same as "New users" because you can sign up for eesel and never become active. So even though we already broke down "Active", we introduced another metric called "New inactive users".

![Fill in the gaps](/a/post/your-metrics-belong-in-a-system/gaps.png)

Note how after this step things should feel exhaustive. You should have terms to capture all building blocks for your business. There should be no blind spots.

### Step 7. Introduce a small number of calculated definitions

You may want to introduce some calculated metrics on top of your canonical metrics for simplicity. Here're some examples:

- For active users, you could define "Net Churn" as Churn - Resurrected, if the latter is pretty marginal
- For revenue, you could use [Quick ratio](https://baremetrics.com/academy/saas-quick-ratio) (ratio of New + Resurrected + Expansion over Churned + Contraction)
- For cash balance, you could define "Runway left at this burn" (ratio of current cash balance over burn)

The premise is that these calculated metrics make it easier to digest and extract insights.

## Wrapping up

You've now got a system of metrics in place. More importantly, you understand the need for systems oriented thinking with analytics, and how elementary concepts like Growth Accounting (along with waterfall charts) can take you pretty far.

I'd suggest reading this [post by Reforge](https://www.reforge.com/blog/north-star-metric-growth) and this [post by Tribe Capital](https://tribecap.co/a-quantitative-approach-to-product-market-fit/) to complement content we've covered. These were key to our understanding at eesel, and we're grateful for them.


Your metrics belong in a system

Improv comedy is a kind of theatre where performers create unscripted scenes based on prompts from the audience. I've been doing improv for 3 years and I often catch myself thinking that the framework used in improv applies to product pretty well.

![Improv and Product](/a/post/your-product-is-a-joke/foundations-comedy-product.png)

## Build a _base reality_ before you get too creative

The base reality in any improv scene is the "who, what, where" of the characters on stage. For example, a base reality could be two friends (who) having lunch (what) in a park (where). When you're on stage with eyes peered on you, there's a natural _rush to be funny_ but we need to resist. The base reality needs to be laid first and in fact, it doesn't need to be funny. It needs to be clear and serve as a neutral background for the funny things to contrast against.

The key product lesson is that you should understand the world you are in before you do anything else. This is the base reality of your product. Who are your customers? What are their problems? What do they do about these problems? What part of the existing solutions will you _not_ change? Resist the natural _rush to be creative_ with features, designs, engineering _-_ and first observe and understand your base reality. The base reality _shouldn't_ be innovative and you should be careful about contriving it to be what you wish. Be specific and truthful. Here are some examples of base realities.

![Some base realities products started with](/a/post/your-product-is-a-joke/base-reality.png)

## Stop and get really explicit about your _game_

Once a base reality is established, improv performers look to find _the game._ This is the _unusual thing_ that stands out, and everything funny revolves around. It's really important for improvisers to explicitly _frame_ the game (with a shocked reaction, a confused question, a dramatic pause and so on) so everyone (including the audience) understands what's unusual.

<div data-type="video-player" style="margin: auto; max-width: 560px;">
  <div style="padding-top: 56.25%; position: relative;">
    <iframe  style="display: block; position: absolute; height: 100%; top: 0; width: 100%;" src="https://www.youtube-nocookie.com/embed/FQ5YU_spBw0?start=59" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen>
    </iframe>
  </div>
  <em>In this sketch, the line "Are there any women here today?" explicitly frames the unusual thing. There are indeed women dressed as men.</em>
</div>

It's similarly really important that you pause and get explicit about your product _game_. Be clear and aligned as a team about your unusual insights and beliefs. These will likely be your most critical assumptions and form the basis of your innovation. Your insight could be a specific take on the problem, the technical approach, the distribution, the trends in the space, and so on. Here're some examples.

![Some games that products found](/a/post/your-product-is-a-joke/game.png)

## Look to explore or heighten, but maintain focus

There's a natural tendency in improv to bring in _lots of_ _games_ because we're afraid about _not being funny enough_. However, the funniest scenes are funny not because they have multiple games, but because they take a focused game to places no one (even the performers) expects. Improvisors do just that by exploring the game ("if this is true, why is it true?") or heightening it ("if this is true, what else is true?").

<div data-type="video-player" style="margin: auto; max-width: 560px;">
  <div style="padding-top: 56.25%; position: relative;">
    <iframe  style="display: block; position: absolute; height: 100%; top: 0; width: 100%;" src="https://www.youtube-nocookie.com/embed/ohDB5gbtaEQ?start=67" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
  </div>
  <em>In this sketch, the game is constant disagreement, and that's it. Everything else is totally normal.</em>
</div>



This is an important lesson with product too. Resist the temptation to bring in _lots of games_ because you want to _hedge your bets_ or because _it all looks exciting._ Do less, and take it places no one (including you) can expect. Wonder "why" to explore the deeper rationale behind your key insights and reason from first principles. Wonder "what else" to heighten your key insights by deducing second (and n) order impact and peripheral ideas.

## Don't use not knowing your game as an excuse to not start

Some improv scenes are initiated with a generic line and performers extract the game organically. e.g. "I can't believe it's midnight" is an intriguing start to a scene but there's no obvious game. In contrast, some improv scenes are initiated with strong game right away. e.g. initiating the scene with "No, you're an accountant, you can't just become a lion tamer". Both ways can lead to hilarious scenes.

Likewise, some products are initiated with a rough idea. This is in the camp of [Eric Ries' model](https://en.wikipedia.org/wiki/Lean_startup), where you're lean, get feedback, and iterate quickly. The idea is to treat the path to product market fit as a series of experiments with hypotheses. In contrast, there is [Keith Rabois' model](https://twitter.com/rabois/status/1153533967296946177), where you have a strong vision from day 0 and not much changes from then. The idea is that you have a master plan from the start, and you get heads down on executing it. Check this [post by Casey Winters](https://caseyaccidental.com/caseys-guide-to-finding-product-market-fit/) comparing these models with far more nuance.

Of course, ideally you should find your product game _as soon as possible_ to leave more room to explore or heighten. However, you shouldn't use not knowing your game from day 0 as an excuse to to not get started. You should start building your base reality _today_ and see what surfaces. OpenDoor succeeded with strong initial premise, but Slack and Segment discovered their game over time.

## Wrapping up

There are a few things we can learn from improv to build better product. Of course, these insights could be deduced and communicated even _without_ the improv analogy. However, I think seeing strange connections in lateral crafts creates a much deeper appreciation for the insights. Plus, it's fun to geek out on two things you love, at the same time. Hope you found these comparisons as amusing as I did, and hope you have a few laughs with product and improv.

The Paperclip

A single goal for everyone

Other posts

About us

.css-ln8t4g{color:inherit;font-weight:inherit;-webkit-text-decoration:inherit;text-decoration:inherit;}The Paperclip

.css-vmy5fp{color:#000000;-webkit-text-decoration:none;text-decoration:none;}A single goal for everyone

Other posts

About us

The Paperclip

A single goal for everyone