The story of the darkest months of Groove’s history
“I don’t even want to go.”
It all came to a head at my kitchen table at home.
I was talking with my wife, and I was miserable.
Anyone who’s been through it will tell you that the entrepreneur’s journey is full of peaks and valleys, and this was the deepest, darkest valley I’d ever found myself in.
Our product was stagnating, and our efforts to improve it were failing.
Our growth had flatlined, and we had our first “down” month since 2012.
Our team felt overwhelmed and discouraged.
To top it all off, Len, our head of content for five years, told me that he was moving on.
I felt like I was losing every shred of enthusiasm I’d ever had for Groove.
And there I was, fighting back tears at the kitchen table, telling my wife that I couldn’t even get excited about our upcoming company retreat.
The final months of 2017 were the darkest of my professional life, and also the first time I’d ever entertained the thought of selling the company and walking away from it all.
This is the kind of thing that people tell you not to share publicly.
It scares customers and hurts team morale, they say.
But after talking with dozens of entrepreneurs, I know that this is a very real experience for many others, and if you’re building a company, there’s a good chance you’ll go through this yourself.
So today, I’m sharing the first part of a two-part story of some very grim months at Groove, the lessons they taught me, and how we turned things around to rebuild a company that’s never been stronger, more profitable or more well-positioned to remain successful for many, many years to come.
When “scrappy” caught up to us
A few years ago, we went through the process of developing our team’s core values.
The goal was not to create aspirational values that we could work toward, but rather capture the best qualities we already had.
One of the values that emerged from that exercise was “Scrappy”.
It sounded great, and we had truly lived that value since the early days of Groove.
We had learned how to make do with less and hack things together because we had to.
We had no resources and no time. We had to do whatever we could to get what we needed out the door.
Unfortunately, while it was a critical part of our success in those early days, it also turned out to be a double-edged sword.
Years of scrappiness had resulted in technical debt and a product that was bursting at the seams, unable to handle the volume of data that was flowing through it.
With every passing month in 2016, we were receiving more and more messages like this:
We still had a profitable business, and new customers were still signing up thanks to our marketing work, but we could feel the tide turning.
You can have the best marketing on the planet, but with a faulty product, it will mean nothing in the long run. Click To TweetTo truly scale, your marketing and your product need to deliver.
Looking at our customer feedback, our app’s performance, and our NPS results, we knew that we had to do something.
The problem was that our technical debt—which started accumulating when we built the first version of Groove in 2011—would make repairs slow and difficult.
We couldn’t just patch things up; after talking with our development team, it was clear that the best long-term choice for us would be to rebuild everything.
And so that’s what we decided to do.
There are smart people who would disagree with this approach.
“Just iterate on what you have,” they’ll say, “work with your customers and build on top of what already exists.”
And it sounds far more reasonable than tearing everything down and starting over.
But that would be a short-term fix.
Rebuilding wouldn’t just be a way to solve the problems we had today, it would put us into a position where we could quickly and efficiently move to make the updates we’ll need to build tomorrow.
It would also allow us to continue to take care of our customers and provide increasing value for them over the long-term, something our existing structure was starting to inhibit.
On top of all that, we know that our competitive landscape is changing rapidly, and this industry will look very different in five, 10, and 15 years. We had to set ourselves up to move fast enough to compete in the future.
I intend for Groove to be around for at least that long, but in order to do that, we needed to have a codebase that we could be nimble with so that we could play a role in building the future of this industry.
Takeaway: Being scrappy is great when you’re just starting out and have no other choice. But scrappiness doesn’t scale. As your business matures, you’ll pay for your earlier scrappiness, and you’ll need to be much more thoughtful and forward-looking with your decisions.
Missing our mark
Our plan was a sound one…in theory.
If we rebuild the product into something that our team can more easily work with, then we’d be able to make all of the updates and improvements we knew were needed.
The only problem?
I didn’t realize how big that “if” would be.
We broke the rebuild out into several projects and got to work.
Unfortunately, we never got far.
For reasons I’ll explain below, we missed deadline after deadline, and our team struggled to bring our ambitious plans to life.
Because of these delays, our NPS was steadily declining, our brand was suffering, and our customers were losing trust in us.
As a founder, getting emails like this while you work to rebuild is heartbreaking:
Getting to the bottom of things
As a non-technical founder, I couldn’t understand why these development projects continued to miss their mark.
I grew frustrated, angry, and anxious as I watched the customer complaints pile up with seemingly no end in sight.
And worst of all, I felt helpless to change things.
But I tried to channel my feeling of helplessness into a desire to sort things out.
I began to look at the problem from every angle that I could.
I talked to every member of our team, asking them why they thought we had the struggles we did.
I talked to a lot of smarter and more experienced entrepreneurs, asking them the same question.
That investigation and reflection led me to realize some important things.
What I discovered
From what I could see, there were four key obstacles standing in our way:
1. We didn’t have the structure to scale up
Companies that were succeeding at our stage all seemed to have a lot more structure than we did.
This wasn’t necessarily surprising; until now, we’d done nothing to create any real organizational structure, preferring a flat company which had seemed to work so far.
But it was jarring because it made me realize that a critical part of our organization—its structure—wasn’t working anymore.
I had to do some hard thinking about what our team looked like, and what our team should look like.
2. We didn’t have the right people in all the right roles
As I asked pointed questions in my monthly one-on-ones with each developer, like…
“Why do you think we’re missing these deadlines?”
“What do we need to do to hit our targets?”
“What should we do differently?”
A common theme began to appear.
We weren’t succeeding in this big development project because we didn’t have the right people in the right roles.
We weren’t used to mapping out careful specs for every project or designing products in a way that ensured they’d work before we wrote code.
And because of this, we ended up having to rework, redesign, and re-spec nearly everything. This led to a lot of messy code, missed deadlines, and low morale.
Our internal surveys confirmed this. The Q4 2017 survey results were the worst I’d seen in the history of the company.
With poor organization, low morale, and gaps where we should have had highly skilled specialists, we weren’t set up to win.
3. We didn’t have the discipline to execute quickly
Years of tackling projects with poor planning trained us to work with the suboptimal structure, rather than change it.
Everything about our processes was built—subconsciously—to expect long development timelines and redoing work.
For example, we always budgeted a lot of time for QA and rebuilding, far more than a team with “measure twice, cut once” discipline would.
It was a huge mistake on my part to allow us to get to this point, and we were paying for it.
4. We were living the pain of going from startup to scale up
Ultimately, the biggest factor in the struggles we faced was that it was new territory for us.
As Marshall Goldsmith says, “what got you here won’t get you there”, and I was coming to the realization that going from starting up to scaling would require a different approach and some new skills.
Rebuilding to scale up
It was clear that, at best, we weren’t in a position to succeed beyond where we were.
And at worst, we weren’t even in a position to survive for the long-term.
Ultimately, our business lives and dies on our ability to provide a helpful, enjoyable and consistently rock-solid experience for our customers.
That ability was at risk, and there was nothing more important to our survival than fixing that.
These realizations led us to make some difficult, complicated, and massive changes to our team, our processes, and our product.
And now, we’re looking at a future that’s very different from the bleak one we faced just a short time ago.
Next week, I’ll share the five key changes that have allowed us to rebuild the company and reignite our growth. Stay tuned…