I’ve been on a heck of a journey with the Windsurf team. I’ve had the chance to learn a lot during my time building alongside the team and I’d love to share a bit more what I’ve learned along the way.
At the time I joined, our core product helped people write software faster through an editor plugin. We supported all major code editors such as VS Code, JetBrains, Vim and more and also provided chat-with-code functionality to more GUI-forward editors like VS Code and JetBrains. This feature set solved two use cases: writing code and understanding code faster which were two core things most software engineers do.
Our team grew fast. We went from doing company-wide stand-ups every day to offices in different cities, moving HQs twice for more space and building up other team functions like marketing, recruiting, sales, deployed engineering and more.
The team was growing and so naturally, the product was also growing. The problem was that our core product was an extension, not a platform. We weren’t in control of our own destiny. The VS Code API would change, breaking our features depending on it. Other times, we’d want to build a feature, only to realize there was no native way to build this feature and forcing us to do impractical approaches. Our approach needed to change.
In late August, we committed to building the Windsurf Editor. The team worked harder than ever, built non-stop, and then shipped something first-of-its-kind. The product went viral for its agentic capabilities that unlocked a new way for builders to write software. Combined with a delightful UX, it was the cutting-edge way for builders to write end-to-end software.
After the launch, the team shipped relentlessly. We launched our pricing model, iterated on our release process, shipped countless features that users asked for, and relentlessly refined existing features to eliminate any bugs because users ultimately cared about quality. We also grew a fantastic marketing muscle as a team, built out a support arm, and heavily invested in our community. On the enterprise side, we grew a stellar deployed engineering team and had a killer sales team. Finding escape velocity was just the beginning—the work never stopped and that’s because this space is so competitive.
This journey has been a roller coaster dream. Given the recent news around Windsurf, I took the chance to look back and reflect on a few learnings I had.
An approach to building well-designed products
I’ve found that these three skills constitute the building blocks to creating a well-designed consumer product:
Perception: This involves sensing that there is a problem with the product or there’s room for improvement. This can be done in many ways: external feedback, dogfooding the product, internal feedback, analyzing metrics, etc. The product may work, but there’s a lot of opportunity to improve it further. In software development, this is the equivalent of identifying a suboptimal function but not knowing how to fix it. For example, one common problem for many features is the lack feature discoverability.
Conceptualization: This involves figuring out the conceptual solution. In Windsurf, it involved understanding the problem and then figuring out how to identify a solution starting from the user needs. The conceptual solution frequently comes in two forms: user requirements and design. For example, in the case of feature discoverability, we proposed a lightweight UI system to introduce users to new features.
Implementation: This involves bridging the concepts to reality by implementing the proposal in code. This is typically the focal point of most engineers and is also one of the biggest beneficiaries of AI code gen.
Great engineers are great at #3. Great product engineers and product managers should be good at #1. Designers and consumer product managers should be good at the design part of #2.
In traditional product development, each of these skills are translated to a role—product managers define the problem, designers craft the experience and engineers implement the solution. However, handoffs cause problems: miscommunication due to context handoffs, slower development time due to larger team sizes and lack of centralization which causes slower decision making.
The opportunity is that people are good at many of these three skills. How might we leverage an engineers ability to be amazing at problem perception or solution conceptualization?
For conceptualization, one approach we took was we reduced the cost per problem by defining extensible UI patterns for different use cases. Once the pattern is evident, it’s easy for any engineer to extend it. The main cost is needing someone to establish the system.
At Windsurf, we reduced the cost of problem perception by encouraging dogfooding. This brute force approach works great because the cost of prioritizing a problem is smaller than the cost of identifying a problem, meaning dogfooding allows us to have a very high volume of problems to audit. Once it was the cultural expectation to dogfood and share problems, half the work was done. The remaining work was purely prioritization and implementation. This leads to the next point which is…
Tighten the feedback loop
How fast is each feedback cycle? Because of how fast paced the AI code gen space is and the lack of a clear moat, one of the best differentiators is engineering velocity. The fast engineering velocity comes from companies that have figured out a way to accelerate the feedback loop.
The reason why we had an extremely fast iteration loop was because:
Our product was religiously used by the team to build our product. Everyone has their own intuition on the product, leading to many opinions on the product that are shared during dogfooding.
Our team was in-office five days a week. This allows us to gather feedback with the tap of a shoulder.
Our team builds extremely fast and works extremely hard. Late nights were the norm, not the outlier.
This fast iteration loop allowed us to efficiently navigate through many unseen iterations of the product only to land on an objective improvement over the existing product. We packaged those into what we called a “Wave” and launched these updates at the fastest rate in the AI code gen space.
Design is a differentiator
This was a quote from Dylan Field, CEO of Figma, during one of his keynotes this year. We were able to experience this first-hand as a product that not only cared deeply about engineering capabilities but also design craft.
When someone uses your tool for most of their week for their livelihood, the details and the design couldn’t possibly matter more. To win in a competitive space, it’s important to understand what’s in and out of your control and design is always going to be completely within a team’s control unlike models from frontier labs. So much of the value come from the model’s capabilities which is why it’s important to…
Optimize the path to value
Users use tools with a goal in mind. In the age of AI and context engineering, there’s more “delivery time” i.e. time for the user to have their use case solved. Within this period, there’s context-gathering, user inputs, loading times, all of which leave room for error.
During delivery, the following could happen:
System error: network failure or rate limiting or other cause (e.g. Claude might be hitting peak capacity)
Alignment failure: user goal and agent goals are misaligned which leads to the wrong direction (e.g. agent might be making incorrect assumptions)
Design failure: user’s intent was not properly captured by the design (e.g. they may have used the wrong feature)
And more…
Due to the increased amount of moving parts, error rates are higher than traditional software. As a result, in comparison to previous years, software has felt buggier than ever and there’s a desire to return to the previous baseline reliability. An emphasis on reliability and optimizing for these paths are key to keeping users happy.
Designing patterns, not features
One of the biggest problems with AI is that intelligence is evolving so rapidly that today’s capabilities will become outdated by tomorrow. However, an interface that evolves at the same frequency is a consumer’s worst nightmare since it requires them to relearn the interface each time.
While the speed at which intelligence scales won’t stop, there are ways to keep the UI familiar. Notably, instead of finding ways to add new features to the UI, time should be spent on creating patterns or extending them. This ensures that the mental model a user has on the product stays as consistent as possible. After all, a user doesn’t want more features, they want a better product. Frequently, that means that the patterns might need improvement or extension. I write more about this in this tweet thread.
One example of this is comparing the early days of Windsurf and Cursor. Windsurf originally consolidated all agentic entry points to start within Cascade’s input box whereas Cursor had a different entry point for each use case (e.g. chat, composer, bug finder, etc.). This made feature discoverability difficult for Cursor and made learning significantly easier on Windsurf. All of our efforts in improving Windsurf would benefit existing behavior whereas a lot of Cursor’s efforts would only benefit a fraction of their users.
Speaking of competition…
Understand the implication of competition
Building a great product in a vacuum is a completely different ballgame than building against competitors. Users have terribly strong inertia, existing preferences, and so many more behavioral patterns. When building in a fast competitive space, it feels like shooting many moving targets. So what are some of these moving targets?
Who’s my target user and what are their existing mental models?
What are they looking for and what is not addressed?
Who are my competitors, what are their strengths and what are their weaknesses?
The answers to each of these questions change as the space evolves. Capitalize slowly and you might miss your window of opportunity. Capitalize distastefully and it’ll tarnish your brand. Capitalize effectively and it’ll sway users to your product.
In a space where any product could be the winner, it’s important to equip all your users with an answer to “why is my product better than the incumbent?”. As a company, your goal isn’t only to answer this question but make it so obvious that any of your users can relay it to their friends.
Working hard is the norm in a competitive space
This goes without saying. In an industry where everyone is extremely talented and everyone works hard, it goes without saying that working hard is the norm, not the outlier. There’s no such thing as “working smart” or “shortcuts”.
Specifically, it doesn’t mean that everyone’s required to put in 120 hours a week. Some people feel comfortable working late until a certain hour. It means treating work as a priority and a default, meaning regular late nights and even work on weekends. However, I still carved out personal time to make sure I felt recharged and could bring my best self forward everyday.
The most important part is that everyone’s trusted to bring their best foot forward. This type of culture not only encourages everyone to maximize their output, but it’s also fulfilling because everyone feels like they’re doing their best work. No one should join a competitive startup thinking that their best work is behind them.
It’s a marathon, not a sprint
Once we launched the Windsurf Editor, it quickly became apparent that the work was far from over. The product caught fire and we were getting flooded with feature requests as well as figuring out our pricing plan.
The following weeks after the launch was initially thought of as “clean-up”, especially with the holidays coming up. However, it became clear that the launch was far from the finish line. In fact, it was just the start line. It became clear that in this day and age, you’re not given PMF, you earn it. And the price to pay was a promise to the users that you will keep shipping.
Any slowdown was an opportunity for competitors to catch up or for our momentum to slow down. Our momentum was strong, and we did everything we could as a team to add to the fire. We started treating our work as a marathon, not a sprint.
Invest in others
This was my first job where I was more senior and tenure than most of the company. There’s an empowering sense of responsibility with that but there was also some hesitation. Knowing that I was in a position where I could help others, I was encouraged to actively invest in our team’s growth.
I found a lot of fulfillment in helping people grow. I’m not a seasoned manager but I have the excitement to be one. One area I spent time thinking about was how we could grow our non-engineering muscle despite only being engineers. In my mind, I needed to do the following:
How do I assess someone’s strengths and goals?
Once assessed, how do I position them in problems that are important but that also challenge them in those areas?
I spent time understanding what was the right design scope per individual on my team. Those who were good at both skills operated more independently. Others who were perceptive were great to jam with on designs because we’d brainstorm ideas and they’d identify problems with it. Those who were better at conceptualization, I’d assist in scoping out the problem for. Along the way, I’d also do my best to provide feedback.
The role I was placed in was fun because I got the chance to assist the full lifecycle of everyone’s work—from the problem, to conceptualization, to implementation, then launch. The full-stack skillset is valuable because:
It creates a sense of ownership. This feature is their proud work and their fingerprints are all over it.
It reduces handoffs during development. This accelerates the development of the feature end-to-end.
There’s centralized context for a feature. This means that for any downstream questions, there’s no need for asking around because all context can come from that one individual or from documentation that they write.
This is the most exciting type of work to do at a startup—to own important problems and to launch a solution to users.
The team says more about the company than the product
This should be common guidance except this isn’t as measurable or easily testable as business metrics or brand names. Ultimately, companies compete for talent and the main apples to apples comparison that exist are common business metrics like DAU or ARR or leveraging brand names like FAANG or top tier investor brand names.
However, the most important signal is how well you work with these people. Do you like these people? Would you work for these people? Would you want to spend weekends or late nights working with these people? Can you learn from these people?
I’m grateful for my time at UWaterloo and for the many co-ops I had and also for my post-grad work experiences at Uber and Jemi. They’ve given me a calibrated gut feeling for whether a team is good or not. After working with a range of teams, some who are highly dysfunctional but with great optics and others that are silent killer teams, you start seeing the ceiling of what’s possible and the failed paths to getting there.
I really like the Windsurf team and leaders. The universal priority was to build. Quality felt like a shared responsibility. Intellectual curiosity felt like second nature to the team. The excitement for the work was contagious.
My gut felt loud about the team when I got the chance to know them. Nothing was guaranteed like any startup journey. But I was lucky to be a part of this one.
What’s next? We’ll see. But in the mean time, here’s a photo of me with a real Windsurf (it was hard!), and here’s a fun podcast I did with Dive Club!
