There is a whole episode about this on Masters of Scale, which I invite you to listen, but besides that, I've been going around in my mind how important is this in real life to achieve success at work, specially when you are building a product.

I've been working for like 7 years in MedTrainer, building our product from scratch with the mentorship of our founders, and during this journey, we have had many fires, I mean you literally start day 1 with fires, when you launch a product. On this blog, I'll try to recap some of those moments, and will rewind towards if decisions were correct, or if I would do something different today.

I have had for quite sometime a couple of "styles" driven by some quotes in my mindset:

What doesn't kill you, make you stronger.

Move fast, break things.

Specially those two, I think align a bit with letting fires burn, or with the lessons that will come from those experiences.

There is a bug on my system

When you build a product, you want it to be perfect, you want to deliver the best user experience, you want your users to be happy, but as your codebase grows, it also grows the possibility of it to be less perfect, the more moving pieces it has, the harder it will be to make sure all the pieces work good, when the product has pieces that are outside of your control, you are also adding more risk for failure.

We tend to believe that code is perfectly predictable, because it follows a set of instructions, but the thing you have to accept early is that a product will always have imperfections, because just nothing is perfect.

Anyway... I believe you have to decide what are the bugs that you can live with, what are the ones that are not that costly, or that are rare, or that have a workaround, sometimes there will be cumbersome things that if they have a work around you can let them burn, while you focus your attention to something else.

For example, when we built our reports module, we knew some reports may not perform well with a lot of information, but we knew that since the product was brand new, our customers wouldn't have a lot of information for some time, so that could be something that we could work later, while we fixed other issues, like the password reset process, which was at the moment more important.

Dealing with angry customers

Even if your system is bugless, which is probably imposible, there will always be customers that want something different, or that has just different expectations from what the product does, or how it does, or why it does it... I think you get the point here.

In this case, you may want to focus your attention in your most passionate customers, as if they were your loyal beta testers, if they are willing to experience the frustration, along with you, yes, there will be frustration, you should focus on them as they will help you build a better product for the rest, so focus on this one, while you get the other ones get a bit more angry.

Also if you have some customers on whom you rely to be successful, due the amount of profit they bring into your business, even if their requests will take you a bit away from your end goal, I recommend you to not let them down, you should take the money and drive when is there, as long as you are aware of it, and you have a plan B for adjusting the product when they are no longer there. For example, if they are your biggest customer, and your income or grow goals depend on what they are paying you, you should accommodate to their needs, but thinking that you should also be able to turn these off, when they leave, or when they don't make sense, its kind of using this as an experience for the team, also using this as pivot idea that may or not work for a broader audience, because if they are paying for it, it may mean there was something about it that you were not thinking on.

I don't know if I made myself clear with the above paragraphs... but long story short, you will have some customers that you will have to let stay angry, while you focus on others, and this is fine, this is normal, you can't make everyone happy.

Living without automation

Yep, in this IT world, where continuous integration, continuos deployment, DevOps, etc. are the hot words, and are thought and explained in so many places, you can be successful without them, yes you can, you will suffer, you will.

When you are beginning to build a product, spend your time and money on making the product better, on having as many satisfied customers as possible, try to live as much as possible without automation elements, that is fire you can let burn for sometime.

I lived for years without automated tests, without automatic integration and deployments pipelines, I look back, and probably shouldn't done this for more than 1 or 2 years, but got used to that status quo that wasn't challenging me, or the team, but in retrospective I would do it again, I would wait a bit to have automation, if money and time would depend on that.

Fires are normal

I love the quote from Reid Hoffman that an entrepreneur is someone who jumps off a cliff and builds a plane on the way down before it crashes, I think you definitely should get used to fires, and that being a constant in any product or business.

You should think twice, or trice which battles you will fight, and which fires you will put down, as you can let some of them keep burning if they are not important.

I had someone paint me a famous meme, that would remind me this, as even at this time in my professional life, I need to decide which fires are more important to put down.