The first commit I wrote for Squadlytics is dated August 30th, 2017. Using that as an official start date, it will soon be my 1-year bootstrapversary 🎂
Many things happened in the past 12 months:
- I coded!
- I looked for co-founders!
- I ran a beta!
- I launched!
- I pivoted!
- We’re back to beta (now)!
I’m writing this partly because I’ve been asked more details about the pivot, and partly because it’s also nice to take a break to look back at the journey so far.
Part 1: The problem to solve
I worked in teams for the most part of my career and my last job was pretty much to talk to as many companies as possible, to understand what could help them be more productive.
One observation I made was that a project that a group starts right now would take 3 to 6 months to turn into customer happiness and revenues. Putting it the other way, it means that if you see a dip in your sales today, then it’s likely to be some work that started 3 to 6 months ago. And if you start a new initiative today to fix it, it’ll take another 3 to 6 months to see if that thing worked.
So, the earlier you can detect issues in your projects, the easier it is to keep happiness and revenues at healthy levels. Agile methodologies help a lot to achieve that for product development as they provide a continuous feedback loop. But development is just a part (though an important one) of a project, and we don’t have great ways of tracking execution for the work done by other functions.
What I’ve seen in many places, including where I worked last, is that we’d rather update a spreadsheet and send emails than use an issue tracker to report on the status of things.
Let me pause here for a second to talk about progress vs status.
Progress: This is how much of something has been done, and what’s left to do. It answers the question “Are we done?”
Status: This is related to the initial expectations in terms of impact and timeframe. It answers the question “Are we on track?”
You can be done and off-track. In progress and on-track. Not started and at-risk. It’s important to make that distinction.
Back to our post. My point is that today issue-trackers, project management tools are really good at tracking progress. They have great workflows, reports, tools that help you understand how much you have done, and how much there is to do. But, they quickly become too complex when you try to use them for status.
Progress is granular, you want to see lists of thing, details, specific knowledge. Status sits at a higher level. It’s the executive summary that helps compare elements of different nature, that may or may not be related to development, that may or may not have metrics attached to them.
A tool that is designed for low-level details will struggle to give a simple overview of things. And that’s why today we’re still many to update spreadsheets in a weekly meeting instead of using any of the existing project management tools already in place at work.
This is the problem that I wanted to tackle when I started Squadlytics a year ago. To be honest, the paragraphs above are a much clearer perspective than the one I had back then. At that time it was more along the lines of “Can I help teams track stuff better?”. It was a blurry vision of wanting to create a product that would take the pulse of an organization, and be able to raise flags if things were in trouble.
Part 2: Don’t start like I did
At the end of 2016, I was a couple months away from leaving my job and I started to explore some ideas. I ended up making a short keynote to illustrate the problem I just talked about.
It was the story of a small startup looking for a solution to track their goals. I did not know what the product would look like at that time but I could foresee the need for both manual and automatic updates as you can see on slide 10.
Fast forward to mid-2017 and I was ready to pick that keynote and turn it into a product. What I would normally do, is spend a lot of time chatting to people to validate things. But the context at the time was a bit peculiar:
- We (me, wife and kid #1) had just moved to Lisbon in February. We did not speak Portuguese.
- Baby #2 was due for November.
- Even though I kept up with trends in development, the last time I did some serious coding was 5 years ago.
So, the question on top of my list was to know whether or not I’d be able to brush off my dev skills and manage to code while also being a parent to 2 kids under 3. There’s a debate going on about the hours required for a founder to start a business, but I knew that I wanted to have a good work/life balance and that I wanted to be present for my family.
So I went a bit backward. As I was pressed by time, I did a side-project to get my skills up-to-date, then I decided to go with the automated updates and build something.
Why go the automated way, rather than manual?
Time to take another break in that story. I picked the automated rather than manual updates because of a few things:
- I knew that my customers would already have tools in place.
- I knew I could listen to activity thanks to webhooks.
- Automated means, in theory, time being saved.
- I had no idea what the manual updates platform could look like.
It was much easier for me to imagine an automated productivity tracking platform being successful, rather than selling a platform where you’d do manual updates.
Part 3: Building the first version of Squadlytics
The original concept for Squadlytics was straightforward. The app would monitor activity in your tools (Jira, Github, Bitbucket, Heroku), and translate that into productivity metrics. I managed to quickly create a prototype with fake data and took it around to a few people. I wanted to get a few nods before building a real platform.
I got a bit lucky as the first person that saw the prototype told me they’d buy it right away. It felt amazing! Then I spoke to a couple more people to be sure, and while the response was not as warm it was enough for me to get started. I also had some hard deadlines (remember the baby?) which gave me a good sense of urgency. I had 3 to 4 months to see if I could bootstrap a business while also having a family — and I knew that if I waited for after the birth to start, then it would be very unlikely for me to take the leap.
It was a real rollercoaster to get there but the beta was built on time.
What was good:
- Writing a vision document which was defining a purpose rather than features. That has been super helpful to keep track of the North Star and not get too distracted.
- Being ruthless on deadlines, cutting scope aggressively when required.
- Having lines in the sand to help measure traction.
What was bad:
- I totally overestimated how much time I’d be able to spend on Squadlytics.
- Having strict deadlines is really bad for finding co-founders.
- I got distracted trying to appeal to many instead of focusing on a specific team persona.
Here’s how things looked in terms of timing
After running the public beta for about 4 months, Squadlytics was finally made available to everyone in April. Then, in I made the hard decision to pivot last July.
How confusing.
Part 4: The pre-pivot
The first version of Squadlytics was promising and we still have a few companies using it. But as we were making progress, it was also clear that it would be tough to make it a great product.
Building an abstraction layer is hard
The platform was an abstraction layer on top of your development and productivity tools. We were translating information from various tools into our own format to analyze the data and build our dashboards.
That’s cool at the start, but quickly you run into some vendor-specific constraints. And you also run the risk of seeing your integrations breaking if a vendor makes a change to their APIs. That’s fine if integrations are just a part of your product, but much harder to manage if all of your product is about integrations (hats off to the Zapier people 🎩).
Creating a great user experience is also difficult if a big part of your onboarding is owned by 3rd parties. Of course, you can solve these problems but when you’re a team of mostly one person you need to think hard about how much time you’d be able to invest in it.
Activity is only part of the answer
As I was chatting with our customers and showcasing the product, I started to identify a recurring theme.
Productivity metrics can tell you if you’re doing something, but it doesn’t tell you if you’re doing the right things. And as the original goal was to help with status rather than progress it looked like we were going in a different direction.
If we kept focusing on measuring activity it would have also pushed us to implement more and more features to track individuals. And that’s not a direction I was keen on.
So, I went back to the old keynote and created a mockup for a new solution putting more emphasis on status and manual feedback.
Part 5: The Aha! moment
In early June, I went to a dev conference to meet tech people and ask around about team productivity. I was not there to pitch Squadlytics, but rather to see how teams knew they were doing well. I spoke to a few dev leads and it confirmed what I suspected. Rather than using metrics, organizations prefer to rely on peer feedback to know the status of things.
Humans are still much better than machines at assessing situations.
I would only show my mockup at the end of conversations, and right away I could feel a big difference compared to how things were with the first iteration of Squadlytics.
Previously I had to spend time explaining the dashboards, and how it would relate to business outcomes. The discussions were exciting but it required a bit of time for people to see the value. Now, I would get comment right away on how they’d use it. I was touching an existing problem, for a job that people were already doing.
The issue with spreadsheets and wikis for status reporting
It’s clear that docs and wikis are convenient for project updates. They’re easy to read, easy to share, easy to edit. The interface is straightforward and anyone can use them.
But they suck at periodic updates.
- You need to send reminders every week.
- You can’t see the history of updates.
- It’s hard to find the right document.
- It’s hard to know if the reporting is accurate.
Spreadsheets and wikis might be simple to use, but they lack support for recurring feedback. A better solution would be able to offer both: an intuitive platform to edit things easily, with powerful workflows to manage updates.
Part 6: The pivot
Alright! We’re getting to the end of this post. I think.
It was a funny moment for me to realize that the thing I did not believe in ended up being the thing people wanted the most (I suspect that the many years I spent working on automation contributed to my choice of going down the analytics path).
We already had a product with customers on it so we had to make a choice.
(1) Keep at it and stick with productivity analytics.
(2) Launch the project updates platform as a separate product.
(3) Sunset the productivity analytics service and focus on the project updates.
We made a few comparison tables to weigh the pros and cons of each approach, but ultimately it came down to this: when you’re small you can only do one thing right. And then again, it’s still going to be hard, no matter how simple the idea is. So option (2) quickly went out of the way, and I decided to take option (3) and pivot the product.
The goal when starting Squadlytics was to be a health platform for organizations, and this new solution was much better at that. The other advantage was to part ways with the activity-tracking features as I did not want to build a product that could be used to monitor employees.
We’ve been working on the beta for a month now and it’s coming together nicely. In that single month, we have had as many people signing up for early access than we got during the entire 4 months of the previous beta. It’s a long journey ahead but the signs are really encouraging.
What I’ve learned
Some things really helped.
- Set some goals early, it doesn’t matter if you miss them at the beginning. It matters that you set expectations for yourself.
- Track your progress religiously each week.
- Do retrospectives, look at the gap between what you thought you’d do, and what you’ve done. Change the things that don’t work.
- Focus on stories rather than features, it’ll help you cut scope when needed.
- Seek feedback early and often. Don’t take criticism personally.
- Have a vision, but listen to opportunities.
And there are a few things that I would do differently if I could.
- Don’t start a business when you’re having a baby.
- Don’t start a business if both kids are under 2.
- Spend more time testing the market.
- Build more lo-fi mockups and test them before coding anything.
- Ask the money question: would people pay for your solution? How much?
- Slow down when you’re looking for co-founders. Being stressed is not sexy.
Another great way to move fast is to learn from others. I have a 30mins walk to my co-working space and it’s a great occasion to listen to podcasts. I particularly enjoy the following:
- The IndieHackers podcast by Courtland Allen: lots of great stories about how people have started their own businesses.
- Exponent.fm by Ben Thompson and James Allworth : more about big co, but really helpful to think at a higher level.
- The African Tech Roundup by Andile Masuku: I’m really excited about the African tech scene and you should be as well.
Final words
If you’re interested in Squadlytics you can sign up for early access at https://squadlytics.com.
If you have any questions or are interested in more of my ramblings you can find me on Twitter at @stenpittet.
Last but not least, all this wouldn’t be possible without the incredible support of my wife Nerida.
