My startup designer friends, this is for you
sharing my learnings from building a 0-1 product now used by NVIDIA, Rivian, and LinkedIn
Hi there! I’m a senior product designer and creative director at Rootly, a YC-backed SaaS startup working on the incident management solution for tech companies. In the past year I led design of our On-Call product from 0 to 1, and now Rootly On-Call is used by companies like NVIDIA, Rivian, and LinkedIn. I learned a lot along the way and want to share some key learnings with you. I hope these are helpful for designers who are also working in startups or building 0 to 1 products <3
For those unfamiliar, Rootly On-Call is an alerting tool that helps engineering teams quickly identify and respond to system issues while improving overall reliability. Just like how hospital teams coordinate schedules and receive urgent patient alerts, Rootly On-Call ensures the right engineers are notified and can respond immediately when systems need attention.
A "good enough" product that's out there collecting real feedback is worth infinitely more than that perfect masterpiece sitting in your Figma.
"I never have time to perfect my design, it's frustrating." This is what I’ve heard from many designers. Well, I’m kind of a designer myself, and imo “perfection” can be your worst enemy, especially when building a 0-1 product.
Consider this: If you're just starting to build a product with no users, how can you know what "perfect" means? Imagine spending a year crafting your "perfect" product, only to discover that potential customers are locked into long-term contracts with competitors—or worse, that users don't even need what you've built. Therefore, getting users is the key here. Get your product out quickly, gain some early traction, collect real user feedback, and iterate. This process will validate your early assumptions, help course-correct, and take your product to a level you couldn't even imagine.
In practice you might still have the urge to try the million brilliant ideas swimming in your head. To be clear, I’m not saying you should not explore at all, but you are no Doctor Strange, and customers won't wait forever for your product launch. In this case, it’s important to remember getting your creation into users' hands ASAP is the way to bring the most value to your team, and it takes practice to find that balance between quality and velocity.
Think of product development as an exciting journey rather than a search for some elusive "perfect" solution. Be bold, make decisions, ship features, and let your users guide the way. Your success isn't about getting everything right on day one - it's about how quickly you can learn, adapt, and itearate based on real customer feedback. Many of our most impactful and game-changing features in On-Call was far from perfection in the first attempt, they emerged from this iteration > perfection mindset.
You don’t need to be the smartest in the room. Be humble, be curious, ask questions.
When I first started designing our on-call product, I had no idea what on-call or alerting was. I felt like the least knowledgeable person in the room. But I wasn't ashamed of not knowing—after all, I'm not an engineer and have never been on-call. What would have been truly shameful was pretending to know and building a product based on guesses and assumptions.
We all experience imposter syndrome. Especially when surrounded by domain experts, it's tempting to pretend we understand things to avoid looking inexperienced and dumb, or being judged.
From my experience, though, people actually appreciate fresh eyes and new perspectives. Deep familiarity with a domain can sometimes create blind spots, and "dumb questions” help us take a step back and think about why we build things in the first place. It keeps us grounded.
Be comfortable to admit what you don't know and embrace curiosity and humility. Ask questions. Ask the magical "why." I've gained countless valuable insights from our customers, founders, and sales teams just by asking questions. These conversations helped me paint a more complete picture of the problem we're solving, the challenges of the existing tools, the market sentiment, and opportunities we have.
Also asking questions shows you truly care, and your team will love you! — what is more lovable than a good listener?
Hand off collaborate with your engineers
I’ll say it: there should never be a "handoff." The term implies that once you pass your design to an engineer, it's no longer your concern and entirely their responsibility. This creates an unnecessary divide between designers and engineers.
Instead, we should view the engineer-designer relationship as a true collaboration. While our expertise and responsibilities differ—and our involvement naturally shifts as projects move from ideation to implementation—I've found it invaluable to stay engaged in the engineering process. This means understanding which parts of my design cause confusion, what lacks documentations, what design is hard to implement, etc. These moments provide opportunities to reflect on product and design decisions, learn about technical constraints, and build trust with your engineers (after all, you're building buddies!).
When you start truly collaborating with engineers, you'll naturally begin considering things like implementation complexity, potential points of confusion, and what design decisions need clearer documentation. You will find the collaborations is smoother, the implementations are more precise, and everybody is having fun along the way :))
Go-to-market (GTM) matters just as much as building
Over the past year I've built tremendous respect for our GTM and sales team. They excel at demoing our product and providing insightful feedback for improvements. What impresses me most is their ability to help customers recognize their challenges and understand how our product adds value to their team—whether through cost savings, vendor consolidation, or specific features. This has taught me that communicating your product's value to customers is just as crucial as building the product itself.
If building a product means creating solutions, then GTM is about finding people who need those solutions. As ppl say, “you can't help someone who don’t think they need help”. That's where GTM shines — they help potential customers understand their challenges, identify their core needs, and see how your product could bring value to them. This process helps you find the customers who will actually pay for your solution. With good product and good GTM motion, you get your growth flywheel!
GTM is equally important for existing customers. When you already have users, retention depends on delivering lasting value. By effectively communicating new features and their benefits, while showcasing your product's continuous evolution, you build enduring trust with your customers.
But how does this impact product and design? When defining problems and designing solutions, we should put ourselves in the GTM team's shoes. Ask: What value does this feature bring? How will customers benefit? Can we make it more appealing to sell? Having early conversations with the sales team is crucial—the closer you are to understanding the problem, the better solution you'll create.
This mindset also reveals an often overlooked opportunity in design: in-app product updates. While we commonly see changelog updates and website hero sections, what about the product interface that people use daily? There's huge potential here. Communicating feature updates and value within the product itself is incredibly effective since that's where users spend most of their time.
Focus on the outcome, not the responsibilities
Early days in my career i got caught up in debating job titles and specific responsibilities. But I've learned that these labels can actually limit our potential and impact. What truly matters is the outcome we deliver - creating exceptional products that solve real user problems. When we focus on the end result rather than rigid role definitions, we free ourselves to learn new skills, cross traditional boundaries, and do whatever it takes to achieve success. This mindset shift has been transformative for me. Instead of asking "Is this part of my role?" I ask "Will this help create a better product?" This approach not only leads to better results but also accelerates personal growth and learning.
Building a 0-1 product is an incredibly humbling journey. Every day, I'm designing the most impactful product I've ever created and solving the most complex problems I've encountered. These experiences have fundamentally shifted how I work, what I value, and the mindset I bring to work each day. They've helped me navigate the ambiguity and fast pace of building something new. I hope you find these insights helpful as you build the next big thing. You got this!!!
PS: Shout out to the many designers whose stories help me realize I'm not alone in facing these challenges. Their perspectives illuminate where we are as an industry and how our mindset evolves with it. I'm grateful to those who share their experiences, and I strive to become someone who shares and inspires as well <3
Also attaching some Dive Club episodes that I find echoes the main points of this essay:
Jerry casually dropping startup wisdom