I used to think that building products quickly was something only early stage startups could do. I thought that as a company grew, process and layers of additional consideration were necessary before anything could ship. The risk of error in a heavily used, at-scale product were too high for teams at later stage to ship quickly, right?
I've completely changed my opinion on this.
I work at Pinata and still consider it early stage, so I can't base my view entirely on my experience at Pinata or my experience founding my own startups. Instead, I have been looking beyond the walls of early stage. I also had the unique opportunity to experience how products were built at a later stage company first-hand when I left Pinata briefly to work at ClickUp. At ClickUp, quality was a major focus–the company had seen a slew of customer complaints about performance and other quality issues for months leading up to me joining–but that focus did not prevent the various teams from shipping and iterating quickly. The culture of iteration was ingrained in every person from the start with an edict to ship weekly and to always include "quick wins" among larger projects. Despite growing to over 1,000 employees when I joined, ClickUp operated like a much smaller startup while still generating hundreds of millions in annual revenue. But this is still just one data point.
Let's look at an organization many orders of magnitude larger than ClickUp: Meta. When Meta saw an opportunity to siphon off Twitter users as Elon Musk's takeover caused upheaval, they quickly iterated through a few experiments, including making text posts on Instagram more prominent, before deciding to build a new social client. They new they needed to move fast, so Meta leveraged as much of its existing infrastructure as it could and built Threads in just five months.
Despite the apparent advantages of reusing Instagram's platform for Threads (much faster delivery time), Malkani admitted the company introduced a substantial amount of technical debt that must be addressed in the future. The team is working on gradually separating the data models from Instagram's as the Threads service gains new functionality so that both platforms can be separated, but the process will take some time.
Choosing tech debt is generally considered blasphemy if you believe the comments section on Hacker News. However, tech debt is not always bad. In fact, I would go so far as to venture that it is often good. In Meta's case, the options were to spent months architecting a solution that would avoid tech debt before actually building anything or ship and iterate. They chose the latter because it allowed them to capture market share from Twitter.
This decision-making process is something I heard referenced in a specific way on the Startups For The Rest of Us podcast. Rob Walling, the podcast host, was interviewing Noah Kagan, the founder of AppSumo. In the episode, Kagan talked about how he his team approached product development early and how they do so now. His answer was the same for both. He said they focus on "now over how."
The idea is simple. Rather than wasting time considering how something will get done, they defaulted to now. Just build, ship, iterate. This is what we do at Pinata, this is what I saw at ClickUp, and this is exactly what Meta did with Threads. Over-analyzing projects is a trap. Architecture is important. Scale is important. However, those things cannot get in the way of learning, capturing market share, and building the company. The product is nothing without the company. Now over how exemplifies this mentality.
A different way of thinking about this is how Claire Vo, Chief Product Officer at LaunchDarkly, recently put it in an interview with Lenny Rachitsky on his podcast:
I communicate to my leaders that my expectation is they bring in the clock speed one click faster, which means if you think something needs to be done this year, it needs to be done this half. If you think it needs to be done this half, it needs to be done this quarter. This quarter, this month. This week, today. End of day, in this meeting.
People's clocks tend to over-estimate how long things should take. This isn't because they want to work longer. It's because they struggle to find a way to accomplish something that can be accomplished much faster.
The next time you're working on a project and you find yourself mired in the doubts and questions of how you might do it, try diving in and building. Try focusing on shipping something. When you're competing against nothing, something will almost always win.
