While I am driving within the city, my partner often says that in a 30 minutes drive, it will not take more than 35 minutes if I will drive slow and safe. Their argument is on the trade-offs—saving five minutes for what exactly? Moderate speed and being safe add quality to the drive.
I often apply this principle in our technology work, and it reminds me of a couple of interesting conversations in my early jobs.
Early in the my career when I worked as a technical writer, our documentation manager often said it—”Vinish, the time that you take to write an instruction which is not clear enough, will be same if you write it clearly. Think ahout it.” This message stayed with me for a while.
Later after a few months and in the same job while I was trying to design a form in DreamWeaver, My project manager saw something and told me—”Vinish, the time that we take to design a usable form is not more than the time we take to design a poor form.”
I saw it later while working in content, design, and product roles as an IC. The designers and engineers have an eye on faster shipping. We see it all the time that the notion of speed comes at a cost and none of the growing product teams can afford those trade-offs.
Unclear forms, poor usability, unclear wayfinding in the navigation, escalations in support calls, fragmented message and positioning among marketing, sales, and support—it becomes their default because the culture talks about the speed.
When a team ships a product quickly because they are small and they are fast (headquartered in SF or Berlin or Bangalore), and they are bootstrapping—do their customers care that the product team is bootstrapping? No.
If the team says that they product might not be amazing because they are early—do the customers give them a second chance? Rarely.
The product teams do not build their capability to understand these trade-offs between speed and quality. In their opinion, doing an onboarding call by a Calendly invite serves the purpose. It does not. Speed is not in quickly designing it in Figma, or doing the Hubspot set up in 12 hours.
Speed is about the internal clarity, about the standards and product principles, where different people and teams work on the product and not only on code, design, content, or marketing. Karri Saarinen‘s LinkedIn post (opens in a new tab) on product quality inspired a thoughtful discussion in the comments.
Speed means designing a form that is clear and useful, and it builds confidence in the users’ actions.
Speed means that the dashboard shows value and insights to the users via those numbers and graphs.
Speed is in designing the message that answers users’ questions and takes their journey forward.
Speed is being culturally aware and principally committed.
Speed is not in faster shipping.
Just as I wrote recently that the goal of the design principles is to find and set our defaults, speed is in our defaults guided by our collective product sense and product judgement.
Once you are in this zone—you will not prioritize speed.
I read this quote recently but cannot find where exactly—”No one ever told Rembrandt to paint faster so he could create a better masterpiece.”
