I once blew $500,000 on a product that went nowhere.
It was my first real venture into AI, and I was convinced I had a winning idea. I spent months crafting the perfect roadmap, meticulously detailing every feature, every integration, every milestone. We had a brilliant team, a solid tech stack, and what I thought was a clear vision.
Twelve months later, we had a product that nobody wanted. The market had moved on, our assumptions were wrong, and I was left with a failed product and a very expensive lesson. That failure was the best thing that ever happened to me. It forced me to unlearn everything I thought I knew about product management, especially in the unpredictable world of AI. It led me to a counterintuitive approach that has since been the bedrock of my two successful exits and over 200 angel investments in companies like Anthropic, OpenAI, and Scale AI.
It’s not about the tech. It’s not about the roadmap. It’s about a simple shift in perspective that changes everything.
The Allure of the Perfect Roadmap
We all love a good plan. There’s a certain comfort in a well-defined roadmap, a Gantt chart with neat little boxes and dependencies all mapped out. It gives us a sense of control, a feeling that we’re on the right track. I was seduced by this idea. I thought that if I could just plan everything perfectly, success was inevitable. I was wrong.
In the fast-paced world of AI, a rigid roadmap is a recipe for disaster. The technology is evolving at an exponential rate, and what seems like a brilliant idea today could be obsolete tomorrow. A detailed, long-term roadmap is like trying to navigate a maze with a map that’s constantly changing. My first AI product was a classic example of this. We were building a sophisticated recommendation engine, and our roadmap was a thing of beauty. We had everything planned out for the next 18 months. But by the time we were ready to launch, a new, more powerful algorithm had emerged, and our product was already outdated.
We were so focused on executing our plan that we failed to see the world changing around us. We were building a horse-drawn carriage in the age of the automobile.
The “No Roadmap” Roadmap
After that spectacular failure, I decided to try something different. I threw out the traditional roadmap and embraced a new approach: the “no roadmap” roadmap. It sounds crazy, I know. But it’s not about having no plan at all. It’s about replacing a rigid, long-term roadmap with a flexible, short-term framework. It’s about focusing on problems, not features.
Here’s how it works:
Start with a problem, not a solution. Instead of saying, “We’re going to build a recommendation engine,” we started saying, “We’re going to help users discover new products they’ll love.” This subtle shift in language has a profound impact. It forces you to focus on the user’s needs, not on a specific technology or feature.
Work in short cycles. We ditched the 18-month roadmap and started working in 6-week cycles. At the beginning of each cycle, we’d identify the biggest problem we wanted to solve for our users. Then, we’d brainstorm a bunch of potential solutions and pick the one we thought had the highest likelihood of success.
Build, measure, learn. We’d spend the next six weeks building a minimum viable version of that solution. Then, we’d release it to a small group of users and obsessively track the data. Did it solve the problem? Did users engage with it? What did they like? What did they hate?
Iterate or pivot. Based on the data, we’d either iterate on the solution or pivot to a new one. The key is to be ruthless. If something isn’t working, kill it and move on. Don’t get attached to your ideas.
This approach is not for the faint of heart. It requires a high degree of uncertainty and a willingness to be wrong. But it’s also incredibly powerful. It allows you to adapt to changing market conditions, to learn from your users, and to build products that people actually want.
From a $4k Bet to a Gusto Acquisition
This “no roadmap” approach was instrumental in the success of both RemoteTeam and MovieLaLa. At RemoteTeam, we started with a tiny $4,000 investment and a huge problem to solve. The world was shifting to remote work, but the tools to manage a distributed team were clunky and fragmented. We didn’t have a grand vision of building an all-in-one HR platform. We just started by building a simple tool to track vacation days. It was a small, seemingly insignificant problem, but it was a real pain point for our users. That simple tool gave us the foothold we needed. We listened to our users, we iterated on the product, and we slowly but surely expanded our feature set. We added features for payroll, compliance, and HR tools, all based on the real-world needs of our customers. We eventually built a comprehensive platform for managing remote teams, but it was a gradual, organic process, driven by user feedback, not a preconceived roadmap. Eighteen months after our initial $4,000 bet, we were acquired by Gusto, a $10 billion company. It was a life-changing exit, and it wouldn’t have been possible without our flexible, user-centric approach.
The Power of a Niche Problem
MovieLaLa was a similar story. We started with the problem of discovering new movies. We didn’t try to build a massive, all-encompassing movie database. We started with a simple app that let you follow your favorite actors and get notified when they had a new movie coming out. It was a small, niche product, but it solved a real problem for a specific group of users. We used that initial traction to learn, to iterate, and to eventually build a product that was acquired by Gfycat. We found that by focusing on a small, passionate community of movie lovers, we could build a product that they truly loved. We didn’t need to appeal to everyone. We just needed to be the best solution for our target audience. This is a lesson that has stuck with me throughout my career. It’s better to be a big fish in a small pond than a small fish in a big ocean.
Building a Culture of Experimentation
A “no roadmap” approach requires a certain type of company culture. You can’t have a team that’s afraid to fail. You need to create an environment where experimentation is encouraged, where failure is seen as a learning opportunity, and where everyone is empowered to share their ideas. At both RemoteTeam and MovieLaLa, we made a conscious effort to foster this kind of culture. We celebrated our failures as much as our successes. We held regular brainstorming sessions where everyone, from the interns to the executives, was encouraged to share their craziest ideas. We made it clear that no idea was too stupid, and that the only bad idea was the one that was never shared. This culture of experimentation was the secret sauce that made our “no roadmap” approach so successful. It’s what allowed us to stay agile, to innovate quickly, and to ultimately build products that people loved.
The Art of Listening
One of the most critical components of the “no roadmap” approach is the art of listening. You have to be obsessed with your users. You have to understand their pain points, their desires, and their workflows. You have to become an expert in their world. At RemoteTeam, we spent countless hours on the phone with our early customers. We’d watch them use our product, we’d ask them questions, and we’d listen to their feedback. We didn’t just send out surveys or look at analytics. We had real conversations with real people. This qualitative feedback was just as important as the quantitative data. It gave us the context behind the numbers. It helped us understand the “why” behind the “what.” We learned that our users weren’t just looking for a tool to track vacation days. They were looking for a way to build a better company culture. They wanted to create a sense of connection and belonging in a remote environment. This insight was a game-changer for us. It led us to build features like our virtual water cooler and our team-building activities. These features had nothing to do with HR or payroll, but they had everything to do with solving our users’ core problem.
Don’t Be Afraid to Kill Your Darlings
One of the hardest things about the “no roadmap” approach is knowing when to kill an idea. It’s easy to get attached to your own creations. You’ve invested time, energy, and resources into building something, and it’s hard to let it go. But you have to be ruthless. If an idea isn’t working, you have to be willing to kill it and move on. At MovieLaLa, we had an idea for a feature that we were all in love with. It was a social feature that would let you see what movies your friends were watching. We spent months building it, and we were convinced it was going to be a huge hit. But when we released it, nobody used it. We tried to iterate on it, we tried to promote it, but nothing worked. We finally had to admit that it was a failure. It was a painful decision, but it was the right one. By killing that feature, we were able to refocus our energy on the things that were actually working. We were able to double down on our core value proposition and build a product that our users loved.
My Advice to Founders
If you’re a founder, especially in the AI space, I urge you to reconsider your relationship with the roadmap. Don’t let it become a straightjacket that stifles innovation and prevents you from adapting to the ever-changing landscape. Instead, embrace a more flexible, problem-focused approach. Start with a real user problem, work in short cycles, and be ruthless about iterating or pivoting based on data. It’s not the easy path. It’s messy, it’s unpredictable, and it requires a lot of courage. But in my experience, it’s the only path that leads to building truly great products. And who knows, you might even save yourself $500,000 in the process.
Frequently Asked Questions
Is this guide based on real experience?
Every recommendation in this guide comes from direct experience, either from building and selling my own companies, or from patterns I've observed across 200+ angel investments. I don't write about things I haven't personally tested.
How often is this guide updated?
I revisit and update my guides regularly as I learn new things and as the market evolves. The core principles tend to stay stable, but specific tactics and tools get refreshed based on what's working right now.
How should I work through this guide?
Don't try to absorb everything in one sitting. Read through once to get the big picture, then go back and work through each section as it becomes relevant to your current challenges. Bookmark it and return to it regularly.
What if I disagree with some of the advice?
Good. That means you're thinking critically, which is exactly what a good founder should do. Take what resonates, test it, and discard what doesn't work for your specific situation. No advice is universal.