How I think about product at Ribbon
Lessons from two years building at Ribbon
We're coming up to almost two years since I started on this journey that we call Ribbon.
In those two years, the world of product and engineering changed a ton. ChatGPT took the world by storm. Github Copilot paved the way for 100x improvements in programming productivity, and Cursor realized some of these gains. It's a common belief at this point in the cycle that every field will have its Copilot/Cursor moment over the next 20 years, and software will be first.
In most companies, AI has not yet materially affected the way products are built. For us, AI is already accelerating every aspect of product development. We're a small and nimble team (really just three of us who work on product!), so I thought I'd write a bit about how we build products at Ribbon.
Imperatives vs. Experiments
I split every new feature, product or pricing model into one of two buckets: imperatives or experiments1.
Imperatives are things that we have to build. Multiple customers are begging for these features or we have conviction based on hard evidence that building these features will serve a need. Building an imperative feature is relatively low risk, but it can be easy to trick yourself into thinking a feature is an imperative.
Experiments are much fuzzier. We often have a hunch that building an experiment will open up a new way of using our product or lead to radical new results. Experiments can often lead you in the wrong direction. As a result, you shouldn't get too attached to experiments. You should expect most experiments to fail and so you should build with this in mind. Experiments should be as quick and simple as possible to de-risk spending too much time on the wrong direction.
For the first ~year after we started Ribbon, everything we built was an experiment. We had no significant customer base. We tried 4 different products, each time racing to invalidate our ideas as fast as we could.
AI will get better, for free
To my latest count, there are 9 places within Ribbon where LLMs are an integral part of the user experience. In some places we've fine-tuned or even trained our own models, in other places we use OpenAI off the shelf.
From day 1, we've built our user experiences assuming that AI will get 100x better. A common mistake I am seeing today is that companies are building around today's LLM capabilities, forgetting that LLMs will get faster and cheaper very soon.
When we first launched our AI interviewer product, the latency was higher than we wanted and we weren't always able to use enough context to ask relevant questions. Fast forward a couple of months and both of these problems were solved via advances researched by others in the AI field. For example, we were able to implement techniques like retrieval-augmented generation to provide more context to our models, significantly improving the relevance of questions. Build for tomorrow's AI, today.
Accept that you'll discard designs
We have designed 3-5x more product than we've built. I never see this as a waste of time or energy. We have (literally) 100s of product ideas and we use design as a tool to narrow these down. Whenever possible, bring your customers into this process and get feedback on designs.
Building great product is like exploring a cave. There are many false passages and the best way to narrow down the path to the right route is by designing a concept and then deciding not to build it further.
People are bad at prompting
I'm very bearish on products that require their users to write their own prompts. The best products are opinionated, they provide a framework for the user to work within and enable them to do magical things that weren't possible before. In AI-enabled products, the prompt + UI is what forms the opinionated core of the product.
Writing a great prompt is akin to structuring a thought into language as clearly and unambiguously as possible. If the success of your product depends on your users writing great prompts, I think you're closer to an engineering tool or stepping stone product.
I've seen first hand that when most users are asked to write a prompt, they write pretty bad ones! This isn't a slight on the average person's writing ability. It's a natural result of priority. Your users have many different priorities and using your product is just one (potentially small) part of their day. They will spend the minimum energy possible on your product, including any prompting.
I think we will see prompting slowly disappear over the next few years. It will remain in some unique places (e.g. chat), but for most products we will learn how to build a better UX without exposing prompting.
While I'm not ready to consider prompt engineering as an entire field, I'm 100% certain that a well-written prompt can significantly improve output.
Deleting code and product is great
The first time you delete a product or large part of a codebase is scary. You worry about the time you spent building it in the first place. You worry about how difficult it might be to restore.
So far, I've had zero regrets every time we have deleted a feature or even entire product. By the time you're considering deleting something, you probably should have deleted it long before.
Embrace constraints
Constraints aren't roadblocks; they're guidelines that sharpen creativity. I've learned that working within limitations—be it time, resources, or technology—forces you to focus on what truly matters. Constraints compel us to distill our ideas to their essence, cutting out the fluff and delivering core value.
When you're operating with a lean team, you can't afford to chase every possibility. Instead, you make deliberate choices that align with what’s most important. It's a bit like cooking with only what's left in your fridge; sometimes, you end up creating your best dish yet.
Credit to Dharmesh's tweet for the terms