In the early days of a product, you spend you life trying to keep everything alive. You continuously fight fires, whether technical or business related.

Eventually, you get to the point that things are stable, and your plates are all spinning – customers are continuing to register and stay around, you service is keeping an uptime >99%, and there isn’t a disaster waiting for you each day you arrive in the office.

You change gear: it’s now about stabilising things, and beginning to work on features that are outside your minimum viable product. But you keep working quickly – you want to scale product as quickly as you can, and show your customers (who you are closely watching the feedback from) that you listen to their suggestions and are serious about building something that they love.

There’s a great feeling that comes from when a customer asks about a feature or reports a bug, and you can fix it in about 15 minutes. They find it astonishing, and at the time it’s obvious: why wouldn’t you do it right away if it’s an easy fix? Later down the track you learn about unintended consequences, and the complexity of your software is such that every time you do that, you end up breaking something else. You start to learn why Facebook doesn’t just solve every one of it’s problems with a couple of engineers and a 6-pack of Red Bull.

Part of moving quickly at this stage is grabbing things off the shelf where and when you can. Why build your own custom thing when it’s not part of your core? Good examples of this are things like billing and merchant gateways (you’d be mad to build your own), email servers, help desks and so on.

Back in the early days of Schedugram, people said they wanted an image editor to change their images before uploading them to Instagram. They wanted the basics: crop, rotate and of course filters. Anything else was nice to have, but they could live without.

We found something off the shelf: it was called Aviary, and it was an embeddable HTML editor, and it was pretty much all we could find at that point (~2014). It looked like it was built in 2008, because it pretty much was:

It was pretty slow, but hey, it worked. We could tell customers there was an editor, for those who wanted it. It didn’t seem like that many people really cared or used it, but we could tick the box!

Sadly, Aviary the company wasn’t really building the product. They didn’t seem to have a monetisation strategy (pro: it’s free, con: nobody fixes problems), so the product really lagged. As people got more and more used to rich editors in their browser (Canva for example), it was more obvious that it was a pretty crappy solution.

Then they got acquired by Adobe, who didn’t really seem to have a monetisation strategy for it either. It got prettier (dark themes! Less 2008 buttons!) but not really more performant. Fast forward a couple of years, and it was one of the most complained about features – the editor being slow, laggy, not working a lot of the time, filters not being “Instagram-y” enough, and generally a bad experience. There is only so much we could blame that it’s an external tool and company – we said we offered editing, and we offered pretty sub-par editing.

Then we discovered a new competitor. They charged money for the editor, which hopefully meant that they would adequately support and develop it, at least while people kept paying their bills. It was a lot better – editing features were a lot more fine-tune-able, filters were more ‘Instagram-y’ and it was built for the modern web, rather than for Internet Explorer 6.

So we implemented it, and paid the bill. Finally our customers wouldn’t complain about a sub-par editing experience, or so we thought.

I should’ve learned from previous changes – like when we re-wrote the whole dashboard and encouraged people to beta test it for 6 months – that people still lost it when we finally forced them to move over.

When your product is 50+% of a customer’s daily workflow (ie “how they get shit done”), any change is very disruptive for the people used to the way things have always been. It doesn’t matter to them if new customers couldn’t work out how the hell to use your product, because they’ve been through that learning curve and can be ‘in the zone’ now.

So guess what happened when we changed the editor? Chaos.

It’s rare to get positive unprompted feedback about any change, so I’d told the support team to expect a few complaints, and wrote a post about a few minor idiosyncrasies that were different between the two editors (mostly around things like how you “finished” cropping and went to save the post etc). Some people took it in their stride and learned the new editor, and a couple remarked at how much faster and better it was.

Others complained to support about individual specific things that they couldn’t do anymore (e.g. a one-click filter was now a two or three click set of adjustments – still easily doable, but customers aren’t willing to experiment and work out how to do it when they’re in a rush already). Some took to social media to lambast us, disappointed that their favourite single thing wasn’t there. Of course, it didn’t matter that you have 15,000+ customers to service, all that mattered was that one button and that support gave them some quick suggestions about how to fix it, but that’s more clicks and a different workflow.

As with previous changes, it quietens down after a couple of weeks and customers get used to the new workflow. I was lucky that I could throw a few questions to some team members about how to reproduce a particular look or style, and they could spend a few hours (!) working out the right combination of adjustments or filters to get something pretty much exactly the same and telling the customer. Oftentimes, those customers just chose a different style anyway, making that moot.

But we tried to accommodate every request possible, and to the best of my knowledge, there wasn’t anything that was possible in the old tool that people used and wasn’t possible in the new one.

One thing we could have done better is to prepare customers – while every time it doesn’t feel like it’s made a difference, we could have made things easier by pre-announcing the change a week before, or sending some targeted emails to customers who we knew were users of the current photo editor in advance. Some change management can be useful once you reach a certain scale rather than just throwing in smash fixes.

No matter what though, you won’t ever be able to reduce those complaints to zero unless you have a truly crap product to begin with. Have a great and proactive support team who can quickly reply to any concerns, but you’ll just have to weather the storm.