Should you really move fast ?

Ever since I started my first job, I've been told, like many others, that speed is the key to success; particularly in startups.

You should ship fast, fail fast

If you're not embarrassed by the first version of your product, you've launched too late

While I agree with those advices and understand the context in which they were said, and even gave them sometimes, I think they are generally misinterpreted and misunderstood. In some situations, they're doing more harm than good.

I want to question the status quo in this post and share my opinions and learnings from shipping products.

Misunderstanding of speed

Generally speaking, I believe people are naturally able to move fast when needed or when the conditions are ideal for it. The payment gateway if failing, every second of the outage is a potential loss of money; this is a greenfield market, there are lots of opportunities and new active competitors. Those are situations where speed is non-negotiable.

I think the misunderstanding begins when people want to move fast just for the sake of moving fast and there's a permanent pressure on product teams from top management.

On the other side of the spectrum, we have indie makers. With a limited runway to identify a problem, understand it, build a solution, market it and make revenue to be able to continue doing it, moving fast is an essential skill. But my problem with the mindset of people in that culture is what they think speed is : "build lots of products as quickly as possible; focus on what sticks". This is a more random approach and personally, I hate guessing. I prefer data-driven insights. I don't have any proof regarding if that is more effective than taking the necessary time to approach people in the industry you want to work on, identify their challenges, gathers informations about how things are done right now etc. I believe in methodology and replicability. That being said, fumbling isn't really that bad of an idea, especially for people with no prior experience building products to solve problems. It's always better than overthinking because at the end of the day, execution matters often more and by simply building, some learn about execution and develop the instincts to find the right problems. One would just need to pay attention to avoid making that a habit.

There's nothing more valuable than a problem deeply understood and worth solving.

I also suspect that most people advocating for speed at any price are non-product individuals that don't care about product and are only motivated by business outcome.

Missed opportunities of learning

The second problem with trying to move fast is all the missed opportunities of learning. I intuitively believe that to acquire some valuable knowledge, one often need to be exposed to the content long and repeatedly enough; that's the only way I was able to connect most of the important dots in software engineering and other aspects of life. By moving quickly, we often tend to only surface the subject and therefore, never connect to the underlying concept.

Moving fast when it really matters

I've seen lots of teams get burned out, disconnected, and lost interest on the product they're building mainly because of the constant pressure to ship quickly. That often put them in a situation where it's difficult to iterate and way harder to move fast when really needed. Personally, I enjoy working on projects when I take the time to craft every piece, with attention and so far, that has been a major element of success.

Intellectual debt

In the AI era, we are tending to loose more and more deep understanding of systems we are working with. I think it's safe to say that we can see the recent lack of reliability in software. I feel like this is only to get worst and I'm personally deeply worried. The more time we spend designing a system, the easier it is for us to identify architectural problems, spot bug and issues earlier and fix them, before they reach production.

I can go on and on to talk about all the different ways I've seen speed being harmful but I think you get the point.

Some words of wisdom and what I've learnt

I have been building different kinds of software products for the past 8 years. Enjoying the process and constantly learning has been an essential part of what kept me going. It's essential to differentiate movement from progress. Personally, what I consider to be failure is lack of reliability and "soul" in what I build, beyond functionality and value.

Solve hard problems

This mindset also forced me to focus on problems that really matter because you can't justify putting that much effort and care on simple problems that can be solved by anyone or problems with solutions that don't bring a substential value.

Good products in slop era

I don't and can't blame AI and this post isn't about AI. People have been shipping slop way before AI. The only difference is they now have the perfect tool to scale it. I believe it's never been more crucial to build great products. Is this era, there are new expectations. It's no longer about being able to build. The winners are not those who build faster. No. Today, it is about taste and deep problem understanding and I think it was always the case. Building was never a barrier. Almost anyone can build.

I considerably use AI for different kind of tasks and I still consider it to be a tool. Like any other tool, appropriate and relevant for some tasks but not all. AI simply have too much limitations in its current form and has not provided to me more value than I expected from it.

Innovation needs new ideas, new ways of approaching problems and solutions that do not yet exist. Innovation means looking forward, which makes it difficult to achieve with a tool rooted in historical data. That does not diminish, in any way the value of AI. It is exceptionally useful for exploring, prototyping, organizing, digesting vast amounts of information, and even building complete features in well established codebases. The nuance lies in recognizing both its strengths and its limitations, a balance that many people miss.

Start slowly

Building a great product is a lot of design thinking, which can't just be sped up. Sometimes you need to slow down, change environment and explore, get inspired.

Dactolygraphy (typing), violin, swimming are different and far away disciplines I get interested in and for each of them, one of the first things I have been told and truly mattered is to focus on accuracy. Not speed. I've never seen an area of life where you focus on speed over accuracy in the beginning.

As I said in the introduction, speed should be natural : quality of execution should come first.

Start very slowly because the cost of breaking bad habits and reforming, or refactoring increases exponentially with the volume and speed and what seemed to be speed in the beginning is often just a debt.

And like anything I say, there's a middle ground. Starting slowly doesn't mean overthinking. There are a lot of unkowns that can only be figured out with motion. No it's about reflecting, paying attention to details and thinking about scale, before comitting.

It's culture

In some way, I felt morally compelled to talk about this. I took a lot of time to write this post and agree with myself and the best word I found to point to the core of this post is culture. This is not only about speed. There are additional factors to consider.

The culture of care is the soul of any product team. And most just simply don't have it.

For the past few months, I've been building a product with a very small team. We learned a lot and took every problem as a challenge, worth solving for our customers.

With good foundations, we're able to move fast now. And moving fast can be fun. Yes, we move fast because it's fun and only do so when we want to, with no pressure. Most days, we prefer to take our time and enjoy building.

Thanks for reading.