Enzo is the founder of June, 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!).
Before we get going, note that document templates and other links mentioned in this post can be found in this eesel folder.
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.
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.
You can find this in this eesel folder
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.
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.
You can find this in this eesel folder.
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. Here’s a template of the board deck.
You can find this in this eesel folder.
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.