How I Learned to Put Action Before Perfection

I recently celebrated a whole year at Buffer and, looking back, what a crazy year it was. One thing that continually surprises me is the open and transparent culture. Giving feedback and experimenting with the process is all part of the journey.

Over my time at Buffer, I’ve had the fortunate experience of working on a few “startups within a startup” fostered within our product lineup – including Respond, our recently acquired social media customer support tool.

When we first acquired Respond, our CEO Joel had some heady goals to get its interface “Buffer-ized,” squash a ton of bugs and turn the whole thing around – in just a few weeks’ time. A team of incredibly talented people was working flat-out to get this project out, for customers to enjoy, as soon as possible.

Buffer, like my previous employer, SoundCloud, is primarily in the “scaleup” mode of operation, rather than “startup.” At SoundCloud, I was used to taking time on the tiniest of details and then pushing to have those designs engineered in a pixel-perfect manner.

Many designers work like this, which I believe is a logical way of working. But the startup journey of Respond was about to teach me a valuable lesson about speed, action and perfection that would completely change my approach to design.

Ready for the overhaul

I remember that period for many reasons.

I had recently moved back from Berlin, I was staying at my mother-in-law’s spare bedroom with my wife. One Sunday evening I was enjoying a beer (or two) when Joel hit me up on Facebook saying he needed a hand on a new and exciting project. Boom… I was to redesign the Respond interface and only had a few weeks to do it.

I’m always up for a challenge, and so, with my beer goggles firmly on, I said: “Let’s do this!”

So I set about working on this project in the same way I had for years. I looked deeply at what we currently had, listened to all the data and feedback, made sure we understood what the problems were, had a good think, opened up the design program Sketch, and dove in.

Feeling like this was an opportunity for a real overhaul, I went deep and proposed to the team that “Let’s change a ton in one go!”

It had to be perfect…or did it?

The longer I spent with my designs, the further into the details I got – while all the while, more demands were mounting on our team. I felt this had to be perfect. I mean, why would this not be anything but perfect for our customers?

This was the grand unveiling of a whole new world for Buffer, and so I insisted that to succeed, the designs had to be implemented just right… this padding had to be correct, that image had to be just so, and what about those colors over there? So many details, such little time… literally. But I had quickly forgotten one of the major cornerstones of the Lean Startup world:

“The lesson of the MVP is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.” – Eric Ries

That’s what Respond was at the time – an MVP that needed to be done in weeks, not months. We needed to get it out the door fast to start learning from customers. Anything beyond that goal was entirely surplus.

Things were going well, but I had started to bring in an extra level of anxiety and stress by pushing for pixel-perfect translations of the design.

I was driving for extra work where it was frankly not required. I was claiming that these designs needed to be implemented “perfectly” to ensure customer success. Which, when building an MVP, is the furthest thing from the truth.

The feedback that changed everything

This resulted in Sunil, Buffer’s CTO who was helping out on Respond at the time, sending me this email (everyone at Buffer automatically sees any emails being sent out, it’s part of our culture of transparency):

“Hi, James!

It’s been really great getting this opportunity to work with you on Respond and I know how much has been on your plate working in two different areas and then also having to focus while moving back to the UK and taking care of your wife (I’m so glad to hear your wife is doing better!). I’m super inspired with how you’ve been able to balance things.

I wanted to quickly mention that I’ve been reflecting about this week with Respond and the standups and how we’ve all gotten on the same page to improve respond iteratively instead of trying to achieve perfection on the first try. To me it did feel like there was a lot of pressure both on you and on the team to make things perfect on the first try or launch. I think you’ve mentioned a couple times in the standup how we want to the designs to ‘perfect.’ That does make a lot of sense, however I’d love to point out how at Buffer we try to steer away from focusing on perfection, and instead, focus on a bias towards immediate action and learning much faster.

I just wanted to share that when I heard the word ‘perfection’ in the standup, it did catch me quite a bit by surprise, because I think I realized later, we really haven’t valued striving for perfection at Buffer. Instead what we do is strive for action because we know ‘perfection’ will never be attainable (and certainly not on the first try). Through small, easily achievable and positive improvements, we’ll converge on perfection :). To me that also feels more elegant and working smarter not harder because it’s a lot of pressure to put on everyone if we value perfection over action.”

Lean vs perfect

This open and honest feedback is an amazing aspect of Buffer’s culture that always surprises me, even after a year. Sharing ways for others to improve or calling out things that aren’t feeling quite right is still really refreshing to me.

I had read a lot about the Lean Startup movement over the years, and I thought I understood what MVP really meant. But this feedback from Sunil really made me stand up and take notice.

Of course I had design standards I wanted to uphold, but there were aspects of my process that didn’t make sense in an early startup environment that required a more agile approach. With some adjustments, I could really step up my game.

Four ways to undo perfectionism

As a result of this feedback, I started making some big changes in the way I approached design for Respond.

Break a big task into smaller pieces

I began to look at my design process in a much more modular way. I started to approach solutions that could easily be broken down into smaller chunks, so could be achieved in a much smaller amount of time with a high level of quality. This is much like an engineer would separate out their code into smaller functions or modules.

Share early to avoid a ‘big reveal’

I started to open up the design process more and get engineers in those earlier design discussions. Getting technical feedback is great, but it’s also humbling to understand what the bandwidth is and those modular solutions will bend to that. Also, getting the whole team on the same wavelength early removes that “big reveal” and everyone can already start to thinking how to implement from a much early stage.

Communicate more than you think you need to

I started to do away with a formal design hand-off document and relied more on early communication, interactive prototypes (using tools like InVision) and async discussions over tools like Dropbox Paper (though others like Google Docs works just fine).

Wear more than one hat

I came from an engineering background (a long time ago!) and so I got back to it, taking on a little coding and using it as part of my quality assurance. There are many debates around if designers should code or not and I do believe that learning just enough to help with styling can be a really powerful thing. Rather than explaining minute changes with margin, paddings or font sizes, you can just roll up your sleeves and get them done.

Conclusion: Does perfection even exist?

As a designer, I always want things to look and feel great. But SaaS products (and digital products on the whole) rarely work like that. There is always a bug to fix or a better way to do something.

Perfection, it could be argued, doesn’t really exist.

That’s not to say that quality should be the first to go in a project like a startup. I think it’s less about perfection and more about what level of quality can this particular project “invest.”

With an early startup fighting for its life, as long as things look and feel “good enough” then it’s probably good to go. When you need to get your first customers through the door, worrying excessively about margin sizes isn’t going to help!

A “scale up” business with more time might be able to “invest” more in quality.

The key is knowing what’s expected and then adjusting your process to accommodate the needs of the project and the team.

I’m grateful to have gotten the experience and feedback to be able to discover when good enough is truly good enough. It’s made my design more efficient and impactful, and it’s a lesson I’ll carry with me.

Over to you

Do you ever struggle with perfectionism? How do you cope or work around it? We’d love to hear from you in the comments!