How to ship like a startup
Seven lessons from the story of Figma Slides
👋 Welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career. For more: Lennybot | Podcast | Courses | Hiring | Swag
Annual subscribers now get a free year of Perplexity Pro, Notion, Superhuman, Linear, and Granola. Subscribe now.
Mihika Kapoor is one of my all-time favorite podcast guests. Her passion, hustle, and ability to get sh*t done have inspired so many listeners and readers to think bigger and bring more joy to their work. In fact, her podcast episode is the most popular episode I’ve ever done with a non-founder or non-exec.
Mihika was one of the early leads on FigJam, Figma’s first-ever new product launch, and most recently, she pitched and launched Figma’s latest product, Figma Slides, which in my recent survey of readers is already ahead of Apple Keynote and tied with Canva as your most used presentation software. For something that launched less than a year ago (and just went GA last week), that is astounding.
Below, Mihika shares the seven biggest lessons she’s learned about successfully pitching big ideas, getting buy-in, rallying a team, and getting new products out the door—essentially, how to keep shipping like a startup as a company grows.
Check out Mihika on X and LinkedIn, and, if you’re interested in more, she recently launched a live cohort-based course on Maven—Product Storytelling: Pitch & Build 0-1 Products at Your Company—where she goes even deeper on this topic. Her next class starts March 31st, so get on it.
We often hear about companies trying to maintain a “startup” mindset as they grow. They want to build products rather than follow processes, assemble irrationally passionate teams, and empower every employee with a great idea to ship a blockbuster. But BigCo status quo often gets in the way. Based on my experiences building Figma Slides, FigJam, and a few others in development, I’ve learned a lot about how to actually keep teams scrappy while launching products on the ground.
Figma Slides was a bottom-up initiative that came to life through a mixture of prototyping, camaraderie, and optimism bordering on delusion. Evangelizing the idea at hackathons, vision pitches, and product reviews bought our team a small amount of headcount to “explore” the space. But that was all that we needed to sprint to the finish line.
When Figma Slides debuted at Config 2024, Figma’s annual user conference, it proved to be a huge hit. Since the launch, we’ve seen people create millions of Figma Slides decks, and, as of last week, it’s out of beta and available for all Figma users 🙌.
Below are seven strategies for replacing the BigCo status quo with a startup mindset. Regardless of whether you are pushing your own idea within a larger company, fleshing out a new product space, or expanding existing initiatives, these tips will accelerate you, your team, and your company.
1. Replace your PRDs with prototypes
🤨 BigCo status quo: A PM’s job is to write detailed PRDs to kick off projects and keep teams aligned.
🏃 Startup mindset: Speed and experimentation matter more than documentation. Anyone with an idea should be empowered to explore it through prototypes.
Learning how to write a PRD (product requirements document) constitutes one of the hallmarks of being baptized as a BigCo™ PM. But in fast-moving environments, PRDs often fail because:
1️⃣ They block valuable design and eng work.
2️⃣ They are almost never up-to-date, as specs change frequently.
3️⃣ Once a product exists, a PRD is just a watered-down version of the actual product being built.
At Figma, everyone is encouraged to design and prototype—PMs included. Additionally, with the rise of AI-assisted features to quickly get to a first draft, the barrier to getting started is plummeting even further, and PMs are much better off spending their time prototyping than writing docs. Conviction comes from prototyping, not paperwork.
Tips for working without PRDs:
Create a prototyping culture.
If I had written a PRD for every idea we explored for Figma Slides, I’d still be writing those docs. Instead we built, tested, and iterated—fast. Encourage engineers to code their “what-ifs.” Some of them might turn into flagship features.
Here are some of the very first prototypes of some of Figma Slides’ core features: slide grid, focused view, and design mode:
Align in lo-fi.
Use FigJam and quick wireframes to jam on ideas and explore solutions. Speed-run option spaces instead of spending weeks writing specs.
Let design files be the source of truth.
Once you align on a direction, don’t create a standalone PRD—annotate specs inside your designer’s mocks. A design file with notes is infinitely more useful (and accurate) than a text doc.
Invest in evergreen, visual artifacts.
You still need to communicate why you’re building something, but don’t rewrite it for every feature. Instead:
📌 Build a single vision artifact up front—so everyone understands the broader impact you’re aiming for. Think about this as your pitch deck.
📌 Update a strategy artifact each quarter—so teams see how near-term work ladders up.
📌 Invest in visuals—directional designs tell the story better than text ever could.
Two prototypes from the original deck of some core features: AI tone dial and the alignment scale:
2. Build hype by working in the open
🤨 BigCo status quo: Sharing work in progress with colleagues leads to scrutiny of rough edges, depleted trust in the product, and an increased likelihood the project gets killed.
🏃 Startup mindset: Showing behind-the-scenes progress gets key stakeholders invested in the product’s success.
Think of your product as a small flame. Your job? Grow it into an unstoppable wildfire inside your company. Do that by sharing progress early and often. Here’s how:
Light the first spark with hackathons.
Hackathons aren’t just for fun—they’re a launchpad.
At Figma, previous attempts to get buy-in for Figma Slides through traditional pitches went nowhere. But when we built a working prototype at Maker Week, Figma’s company-wide hackathon, everything changed. The demo at our internal showcase took off because:
It was big. Everyone expected small feature demos, not an entirely new product built in three days. One engineer even asked if we had 40 people working on it (in reality it was only eight).
The Zoom chat when I demoed our “Flides” Maker Week project to the company It was funny. We held a live vote for the product name, with ridiculous contenders like “Feck” (Figma x Deck), “Sligma” (Slides x Figma), and my personal favorite, “Flides.” The absurdity of these suggestions made it an instant hit.
It was relatable. To set the scene, I pretended I was a hackathon attendee late for submitting my demo video for Maker Week and used Flides to help me out. The demo mimicked a real-world scenario—being late on a presentation deadline. It resonated because it was exactly how we worked.
Share raw progress async.
Don’t wait for polished releases—share raw progress. One engineer on our team, Jon, posted over 70 prototype videos in Slack before launch. Soon everyone followed his lead. A steady drip of updates builds trust and keeps excitement high.
Turn your spark into a wildfire at the all-hands.
Figma Slides got the green light to launch in beta at Config after it was pressure tested in a real-world scenario—I advocated to use our minimum viable product (MVP) at the first company all-hands meeting of 2024. Though our IT team was wary of betting on unproven software, the team paused new feature development for two weeks to refine the MVP for that moment, addressing bugs as soon as they came up. The demo was the best possible showcase of progress and agility, and the team learned so much about user needs. The flawless presentation in front of the whole company sealed the deal.
Bonus: Share beyond your company.
We launched Figma Slides in open beta at Config so we could gather as much feedback as possible before GA. The team shared some of our early WIP vision on platforms like X (with the GTM team’s blessing, of course), which proved to be an effective way to drive hype.
3. Build a cult(ure)
🤨 BigCo status quo: PMs are responsible for the product and the product alone.
🏃 Startup mindset: A product’s success depends on a team culture so strong it feels borderline religious.
Culture isn’t just a nice-to-have—it’s a cheat code for momentum, creativity, and execution. Here’s how to build one that people want to be part of:
Make it weird.
Inside jokes create attachment. The weirder, the better.
For Figma Slides, the absurd name “Flides” became an internal meme:
Slack emoji? ✅ [Make one for your team today if you don’t have one!]
Workstream names? ✅ [The animations sync? “Flanimations.”]
IRL team photo shoot . . . on actual slides? ✅
The more irrational the name, the stronger the inside joke—and the deeper the buy-in.
Steal each other’s quirks.
Shared quirks = shared identity.
Our team leaned into this, hard. Everyone changed their Slack profile picture’s background to match. A Gen Z engineer always opened chats with “yoooooo”—so the whole team adopted it. Even small things, like entering a group chat, became dopamine hits.
Celebrate like it’s the Oscars.
On launch day, we threw an award ceremony. Red carpet, custom trophies, full production. What started as a joke turned into one of the most emotional moments of the entire project. The team was so hyped, we closed out the office at midnight.
Want maximum inside jokes with minimal effort? Crowdsource superlative awards from the team. P.S. Trophies are $20 on Amazon.
4. Find the believers instead of swaying the skeptics
🤨 BigCo status quo: People work on the products they are assigned to.
🏃 Startup mindset: Players who opt in to their teams build the most successful products.
The Figma Slides team was the most inspiring group I’ve worked with—not because they were assigned but because they wanted to be there. We pulled team members from across the org by spreading the word and empowering the most excited and invested folks we heard from to make the switch. Here’s how to build your dream team:
Find your early adopters.
A piece of feedback I was given early on, that to this day resonates with me, is: If you need to sell someone really really (like, really really) hard to join you, they are probably not the right fit. The best teammates are the ones begging their managers to work on your project. Make sure your project is known across your org (and ideally the whole company) so they can find you.
Look for “run with it” energy.
The best team isn’t always the most senior—it’s the one that can move forward without perfect specs. At Figma, we call this the “run with it” mentality. Find engineers and designers who thrive in ambiguity.
Recruit scrappily.
Don’t let org swimlanes prevent you from reaching out. I love working with engineers and designers both on and off my team. The best part is, if they like working with you, they’ll make the time to help out. If they love working with you, they’ll do whatever they can to join you.
Empower every team member to pitch.
Your team should be your biggest evangelists. The best pitches will actually come from the folks on your team. Ensure that they know when recruiting is a priority and that you are available as a resource.
5. Make every team member a product owner
🤨 BigCo status quo: Research hands off to Design, Design hands off to Engineering, and everyone stays in their lane.
🏃 Startup mindset: The best teams blur the boundaries. Everyone is a part-time PM.
Before Figma, I was told to stay in my lane. “That’s a designer’s job” or “This should be done by a data scientist” were constant refrains. Deviating from the original plan was considered “thrash.”
At Figma, it’s the opposite. Extreme collaboration isn’t just encouraged—it’s the norm. We’re able to improve decision-making and expand the solution space when we lean into the following practices:
Remove the black box around the product and design process.
Engineers shouldn’t be kept in the dark until handoff. Involving them early gives them better context, improves decision-making, and allows them to shape product behavior.
Engineers are often brought into design syncs where product decisions are being made. That way:
Design proposals are already informed by engineering feasibility.
Engineers can proactively contribute insights, not just execute specs.
Go from 0% to 100% together.
At Figma, teams don’t work in silos—they pair on solutions. PMs and designers jam together in a Figma file. Handoffs between design and engineering aren’t just “Here, build this”—they’re real-time pairing sessions, tweaking interactions and refining details together.
The result? A stronger product, fewer roadblocks, and a team that feels true ownership over what they’re building.
6. Remove the wall between your team and your users
🤨 BigCo status quo: Researchers are the only ones talking to users.
🏃 Startup mindset: Everyone on the team engages with users to demonstrate, deploy, and debug products.
One of the most fascinating phenomena I’ve witnessed is that if an employee hears a user directly express and elaborate on a pain point, they will be a bajillion times more likely to act on it than if they hear a secondhand summary. As a PM, your job is to engineer as many of these anecdote-driven crusades as possible.
How to get your team talking to users:
 | A guest post by
|