Pivoting during YC, that's rock'n'roll
Why did we pivot from Chaos? That is almost the first thing everyone asked when I start telling our story. To be honest, I understand.
Hey everyone,
It’s nice getting back to you! Previous months definitely rocked our boat with Sydney. I’m heading back on writing this monthly newsletter for our community, with some twists. Headlines :
Why did we pivot from Chaos during YC
How did we find our new idea
How did we start our closed beta to launch today
TLDR: we’re live on product hunt again! Our new project is to help tech teams reduce code review time and ship code faster. We would love your feedback on our launch, take a look 👇
Why did we pivot from Chaos?
That is almost the first thing everyone asked when I start telling our story. To be honest, I understand. Let’s take a step back and do a quick recap:
The project started in October from different posts on Social Media to test the idea,
with >50 interviews, we were ready to go,
MVP built in two weeks,
first paying user a week after,
accepted in Y Combinator end of December with ~€700 MRR,
reached €1000 MRR beginning of February.
But some things did not feel right. Our main goal is to “build something people want”. To achieve that objective, we wanted to reduce to the shortest extent possible our product lifecycle which consists of us talking with customers, understanding next sprint priorities, shipping the product, and doing it again.
But we had hard times having customers on the phone after them paying.
That kept me up at night. I wanted to understand what was happening, where we were heading with such problematic & strange user behavior.
It was similar to this feeling when the air becomes hotter and you know the thunder will soon be around.
A conference with Rahul Vohra (Superhuman) & Emmett Shear (Twitch) pulled the trigger
So here we are, mid-February, a great revenue growth but this unpleasant feeling still around.
As every Tuesday during the batch, we met with amazing and talented people that built huge successes. That day we had the chance to have Rahul & Emmett.
Long story short, these two had radicals and confronting opinions except on a few subjects. One particularly resonated loudly with us :
You won’t be able to scale if your users love your solution for different reasons.
That was the hard truth at this stage and a piece of strong knowledge for us. We were looking for revenue above all and at some point were selling to different people (COO, CTO, IT Managers) for different reasons.
Our main strength, the ability to build an MVP on another platform (Airtable) led our customers to create their own vision of Chaos. Instead of selling our vision, we were selling their own.
Long story short, we spent the next days looking for the best vertical to focus on and did not like the only viable solution (in our mind): SaaS Access Management.
Neither the founder fit nor the motivation for this topic was at the rendezvous. Gaining skills was not a problem, but creating motivation as we’re in for a long time certainly was.
The decision was made.
How did we find the new pain we’re solving
Pivoting from a project is not easy, especially when you do not have yet another project to jump into. We entered a new phase with Sydney of intense research.
We’ve contacted countless entrepreneurs & tech teams for several weeks knowing that we wanted to work on a developer tool because we were passionate about the subject.
One day, the subject became clear. Since we started, we’ve been constantly trying to improve our code development process and found that the very end of this process wasn’t efficient enough. Code review is in our mind the most important step in the code development process - it’s a dedicated time to learn and share for developers.
Our mantra was always that when you approach code reviews as a learning process, everyone wins.
After talking to more than 100 companies we discovered similar frameworks for shipping code:
A pull request is created
Assigned in different ways
Notifications are poorly handled and people are often pinging again directly
Comments are made on Github and if a conflict appears, the conversation goes on a voice call or in Slack.
We identified two major problems:
Problem 1: Waiting on someone to review your pull request is a waste of time. This can lead to roadblocks and inefficiencies in teams. It’s difficult to dive back into a pull request you submitted two days ago.
Problem 2: Feedback on code is hard to convey between one developer to another. It can be misinterpreted or even worse: not given at all.
So, what’s next?
I’ll share later in a specific article the iterations we’ve been through if that can be of interest for you - for now, let’s dive into our current value proposition.
Analytics is a great way for managers to understand and identify bottlenecks. But this is merely enough to incentivize change. Axolo is a bridge from Github to Slack: each pull request creates a temporary Slack channel where only reviewers and assignees are invited, Github’s notifications (comment, reviews, pull request’s state) are sent in their specific channel and ping who’s in charge of the next step.
At the end of the pull request lifetime, two things happen 1. the conversation is sent to Github to contribute to the code documentation, and 2. everyone is invited to give feedback to each other: public feedback to reward excellence, and private feedback for constructive criticism of your code.
We finished our closed beta last week and are thrilled to share Axolo with you. I’d be happy to answer any question about the pivot or the launch in the comments or in private.
And if you want to take a look at our launch video, it’s here.