I was taking the Unpublic quiz a few months ago, when the results page left my jaw hanging. I had been reading my results, scrolling along the page and then… shwoop! The rest of the page blurred out, and a message appeared on top of the blur. To unlock the rest, I had to enter my email.
I sat there, admiring it.
The branding made the whole experience feel mysterious and exclusive, while the payoff dangled just in reach – the rest of the results just visible enough to tease. The only thing standing between me and the rest of the page was access to my inbox.
Best email gate I’d seen in years – and I wanted it for my own quiz.
I asked Unpublic’s Susan Boles how she did it, and she generously shared her entire quiz building process. (It was just as intentional as the results page.)
Her quiz was built on Tally though, and my forms live in Paperform. So I opened my Paperform support chat and asked if they had the blur-gate capability.
They loved the idea, and in addition to logging it as a feature request, Andrew chatted out a workaround that would give the same result. (More on how to leverage these kinds of scrappy support solutions in the episode below.) The workaround needed a plan upgrade though, so I built the quiz on Tally’s free tier – but the enthusiasm and creativity of that support encounter keeps me singing Paperform’s praises. And kept the rest of my forms on their Essentials plan.
As Paperform scales, I don’t take this level of support for granted. (In Episode 1, Diony shared how intentionally they built their support ethos, off the back of their 3am wake ups as early-stage founders.)
Meanwhile, there’s another tool that has always given me the same kind of enthusiasm and help… until recently, as they too have scaled.
The decline was gradual.
I sent my usual “It would be so great if you did X,” and was surprised not to see a response.
A few weeks later, I hit the same wall. “Any chance X is on the roadmap?” Silence.
Then: “Could you PLEASE add X?” Same silence.
When I hit the wall the fourth time, I didn’t bother.
Turns out the feature already existed and I stumbled on it a few weeks too late.
Now when I hit a wall, I don’t know if a feature doesn’t yet exist, will ever exist, or even already exists – and I don’t bother asking.
Outlier? More like “out the door.”
Read my escalation from the vendor’s side and the CAPS chat looks like an outlier: one frustrated customer having a day. Then the account goes quiet. Requests drop to zero, and that’s a good thing, right?
Well, not if you’re looking at the Bathtub Curve of support ticket (and silence) to churn correlation.
2-3 tickets in 30 days is your sweet spot. They track the footsteps of an invested user who loves your product, is exploring its capabilities, and will shout about you from your rooftops.
4+ tickets in 30 days, meanwhile is a churn risk because it indicates frustration – lots of walls being hit. (Notice, too, that if Unnamed Company above had responded to my first feature request, I wouldn’t have needed those 3 follow ups.)
0-1 tickets? That spells apathy, which is just a defeated variety of frustration, giving it the same level of churn risk as the shouty caps kind of frustration.
Mario Araujo, who ran growth at Penpot and is now running growth at Flosum, closed Episode 5 with a happy version of this Bathtub Curve. He emails Spark, his mail client, whenever he hits a limitation, and they actually respond, weeks later, with the fix. Guess if he’s still emailing – and guess if he’s shouting about them from the rooftops, erm, podcast mic.
Because shouty caps are not the scariest kind of feedback. Silence is.
In the episode
What did we dive into in Episode 5 of Churn Flags?
Mario has a spiky POV on why onboarding checklists and product tours exist at all – and it’s got little to do with the users and what they need from us when they join.
He also kills the idea of straight-line onboarding, built from working with roughly 30,000 new signups a month and nine distinct first-session use cases across only two personas.
And of course, we dive into the invisible fixes the community ships, what it costs the company, and the erm, non-invisible fix for the fixes.
Listen & subscribe:
Apple Podcasts · Spotify · YouTube · everywhere else
Which of the nine Change Flags are flying in your product?
Take the Change Flags™ Quiz. About four minutes, scored head to head against a composite of your competitors, with a dollar figure per flag and a 90-day recovery plan.
Read the full episode transcript
Nikki Elbaz (00:00) If you wanna move your design files out of Figma and into Penpot, there’s a tool that does it. There’s a Figma to Penpot importer and it sits right in Figma’s marketplace. Which is kind of funny. Here’s what’s even funnier. Penpot didn’t build their own importer. A bunch of Penpot users built it, published it, and Penpot found out afterwards. So the one touchpoint standing between a Figma user migrating to Penpot – the build you would put on top of your roadmap and guard with your life – was built by customers. This is not a one time occurrence. Penpot is open source, and when a user hits a wall, they don’t complain, nor do they leave. They open the source code and they fix it. Then they publish the fix for everyone else. Sounds like a dream? It is. If there is any SaaS out there that is immune to what this entire show is about, it’s Penpot. Before there are any churn indicators, there’s already a fix. That is generated by the customer base itself. But there is a catch. Because if you’ve been here before – this show is not about churn how we traditionally describe it. It is not about feature gaps. It is about communication gaps. So yes, true. If a missing feature is the reason that an account wants to churn, Penpot will not be as affected. The account will just build the feature instead. But if the missing piece is communication, then Penpot still faces change flags. And that’s also why this episode is relevant to you, even if you don’t have the luxury of customers building fixes for you. Here’s how this show works. Every episode I hand my guest one piece of real customer feedback. A three-star review, a Reddit rant, a puzzling survey response. Together we trace it back to what the feedback is actually telling us. Not the surface ask, the shift underneath it. Because the SaaS playbook has trained us to read feedback one way. As a feature request, a line for the product backlog. Something to fix or politely decline. What that misses is that feedback is usually waving a flag that something has changed for your user. And they’ve started reevaluating how you fit into their life. I call these moments change flags and there are nine of them that matter. Three happen when you change your product, three when something shifts in your user’s life, and three when something shifts in the market at large. Catch one late and the user just slips away. No complaint, no warning, gone. Catch it in real time and the same moment flips. They go deeper, they upgrade. They add seats or usage that they didn’t know they needed. Same flag, two outcomes. And we’re obviously aiming for the second. We’ll end off the episode with a theoretical experiment that we’ll build live to address the change flag. Or, like in this episode, our guest will show us what they’ve actually built and how it’s working out for them. I’m Nikki Elbaz, bringing 15 years of SaaS marketing to these experiments. Welcome to Churn Flags. One thing before we start, customer feedback is the most reactive way to spot a change flag. In the work I actually do, we catch them from a whole slew of proactive indicators. And feedback is the last piece and the smallest. It’s just the one that’s easy to talk about publicly. If you’re suspecting that you’re not tracking some of these indicators, you’re probably right, not enough SaaS companies are. So you’ll want to take the Change Flags quiz. It takes about four minutes. And gives you an awesome scorecard complete with a line by line breakdown of what each flag is costing you. Find the quiz at nikkielbaz.com/quiz. Our guest today is Mario Araujo. He is currently the Head of Product Growth at Flosum. But when we recorded this episode, he had just left growth at Penpot, where he was working with enterprise accounts like Spotify, the US Postal Service, the Swiss National Bank, and the US Army. Penpot is a Figma alternative, a design platform, but with a cult-like following. Because it’s open source. The source code is public. So anyone can go in and change it. Which is exactly what we’ll be talking about today. Normally we open with a review or a story or an email. Some specific piece of feedback. Pointing to a specific flag. But in today’s episode we have something unconventional. Our evidence comes in the form of a build.
Mario Araujo (03:41) People will tell you, need to bring my design system, imagine a team of 25 designers. It’s impossible that they will start from scratch. For big teams, mature teams, it doesn’t happen. So what we did was we launched the Figma importer in Figma’s marketplace. So you can install that, get your Penpot file out of your Figma, and you’re good to go. We were always asking ourselves, when will Figma kick us out of their marketplace?
Nikki Elbaz (04:07) I was wondering that too. Like how did you get it in the marketplace? Yeah.
Mario Araujo (04:09) Yeah. We didn’t do it – actually was another group of people that did it outside of the community, but we –
Nikki Elbaz (04:15) Wow.
Mario Araujo (04:16) – ended up sponsoring it. The community is good answering questions, but it’s also good fixing issues. Because it’s open source, there’s this dynamic of, yes, someone asks a question, they will get an answer. Someone hits a roadblock or needs a feature, they just go in and build it for themselves, publish it for everybody else, and they don’t even speak. So there’s this dynamic is hidden and it’s very open source. It’s hidden –
Nikki Elbaz (04:40) Yes.
Mario Araujo (04:40) – as in. You don’t see this happening unless you’re in Git, who is changing what.
Nikki Elbaz (04:46) At a normal company, when a user hits a wall, one of two things happens. They get in touch with support and try to push you to fix it. Or they start looking elsewhere. That’s it. Those are their options. And that’s my day job. Catching the users who are starting to look elsewhere. And this episode is so fun, because the proactive stuff that I usually look at to catch these change flags early, it’s private. It’s inside somebody’s company under NDA. At Penpot, it’s right there in GitHub. For all the world to see. Every issue, every pull request, every plugin that somebody built. It’s all there. Somebody needs something, somebody builds it, somebody publishes it, and goes back to work. And what they shipped is now part of the product. Which means we’re looking at a features flag. Anytime your product changes, a new capability appears. And the people who need the capability are going to reevaluate based on whether they know about this new capability or not. Except that this is anything but a normal features flag. Run the usual features playbook against this and nothing matches. Who owns the launch? Nobody. The company didn’t build it. When is the announcement? There isn’t one. Who ships the pop-ups? The team barely even knows that there’s something to share. The product gets better. And there is no communication attached to it at all. That’s not a bad launch. It’s not a slow launch. It’s just not even a launch. And in the case of the Figma importer, this is especially troubling because it’s a tool critical to their acquisition and expansion strategy.
Mario Araujo (06:06) There’s a ton of people coming in from Figma. Maybe 50% of the signups that we were getting were coming from Figma. And we –
Nikki Elbaz (06:12) Mm-hmm. Wow.
Mario Araujo (06:14) – were getting maybe close to 30,000 a month or something. We were very much focused on activating users and retaining users before they became customers even. So it was just about building the user base. It has an extremely generous free edition, which delays payment a lot. It’s intentional, but it’s what happens. Everyone talks about straight line onboarding. Let’s create this straight line onboarding. For a product like Penpot, it’s impossible. You have developers coming in, designers coming in. Developers may want to check how easy it is to design for them, or they may want to check the quality of the generated code. Designers may want to see if they would feel at home designing, but they also may want to test the limits of design systems or design tokens. Just in the last 20 seconds, I said five use cases, there were nine in total, just for these two personas. And we’re not even talking about collaboration.
Nikki Elbaz (07:07) Nine segments across two roles and we’re only talking about individual users. Penpot has thousands of designers. Remember, 30,000 new signups a month who don’t read code and will never open GitHub. And they are just as self-sufficient as the devs. Here’s where it stings. The importer, the one we mentioned earlier. The one that strangers built and put into Figma’s marketplace. It’s underused. The plugins, the fixes, the things that people build over the weekend. All of it has to reach the other users somehow.
Mario Araujo (07:36) The only thing that we did at Penpot was to have this pop-up for their next sign-up where we would say, hey, this is what launched this week, for example, or yesterday. And they would slide –
Nikki Elbaz (07:46) Mm-hmm.
Mario Araujo (07:47) – through like five or six things that we would have launched. And that was that. It’s hardly an optimized experience.
Nikki Elbaz (07:53) This is a perfect example of what I get hired for. I run retention and expansion sprints for SaaS companies past $50 million in revenue. Where the obvious retention work is long done. And whatever’s left doesn’t have a best practice that we can just copy and paste. Engaging with me starts with a change flags audit. Your product usage, your support volume, your lifecycle emails. We look everywhere for change flags that nobody is tracking. Then we prioritize the ones that are costing you the most. And we build the fix. Not a recommendation deck that your team has to find time for. We work on the actual thing together and ship it. Head to nikkielbaz.com/sprints for more details.
Mario Araujo (08:28) The catalog of plugins was in Penpot’s website. Still is, right. You browse through the plugins and then you would have to download the plugin, go to Penpot, import the plugin from your hard drive. And so there was a lot of friction to get a template or a library or a plugin into Penpot. Realized that people were having trouble bringing them in and wouldn’t know how to bring them in, we didn’t create any tour. We didn’t create anything for that. What we did was actually create a deep link between the website and the product so that when they click –
Nikki Elbaz (09:01) Mm.
Mario Araujo (09:02) – it would open Penpot and they could continue from there.
Nikki Elbaz (09:05) That’s actually pretty unique. And much more effective in some ways than a product tour. Sure, the friction is rough. But the education around it is seamless. The plugin catalog is where the community’s work lives. It’s where all those fixes end up. So instead of explaining that, they just lead the user there. And actually it makes even more sense given how Mario looks at onboarding.
Mario Araujo (09:25) Another default we see is people creating onboarding checklists or tours. I think these things exist because development product is slow. So it’s a stopgap. It’s not a solution. And I haven’t seen any of these things work for complex products like Penpot. It’s connected with, there’s no straight line onboarding. So there’s no one checklist for these things. I think progressive disclosure is a better alternative.
Nikki Elbaz (09:54) Yes. Progressive disclosure is basically why I created this show. Instead of shoving everything down our users’ throats, or just not showing up enough at all – we show each user a capability at the moment they’re ready for it. This should be obvious, but for some reason it’s not. Well, because we’re just not tracking the right things. We need to track much more nuanced indicators to allow for these perfectly personalized experiences. We need to pay attention to the right data so accounts stick around right as they’re thinking about alternatives, and expand exactly right when they’re ready for more. That data depends on so many factors. So there just can’t be a standard playbook for it. So instead we end up with a bunch of flat best practices. That can fit any company, even if they don’t truly fit the user. Don’t mind me, I’m getting off my soapbox now. Let’s wrap up. Penpot’s users don’t just tell them what’s missing. They fix it. The product problem solves itself. Over and over, for free, which is pretty awesome. But free fixes do not let you off the hook. The fix goes into a repository and thousands of users don’t know it exists. Because a capability shipping and a capability showing up are two different events. And in Penpot’s case, the team has very little control over the shipping part. What does this look like for a non open source company? An engineer who got annoyed by a limitation and fixed it in a sprint, closed the ticket without writing release notes. Or infrastructure that got faster, and the limit that keeps firing doesn’t apply anymore. Support chatting out a workaround ten times a week. A workaround that is functionally a feature. But no one looks at it like that because it’s support chatting it out. It’s just a workaround. None of this goes through a launch. There’s no owner, there’s no email, there’s no release notes. Because technically nothing was shipped. Same thing as Penpot’s plugins. Yet every one of them is a change flag. The product changed, and your user still thinks you can’t do XYZ because you didn’t used to do XYZ and you never told them that you now do XYZ. So think of this as an anti-audit. Instead of searching for what’s missing, list out what gaps you closed in recent months and figure out how to communicate those to existing customers. If you think there are flags flying in your company right now, you are probably right. Take the Change Flags quiz. It runs you head to head against a composite of your competitors and line items what each flag is costing you. Head to nikkielbaz.com/quiz and four minutes later, you’ve got a scorecard with a 90-day recovery plan.
Mario Araujo (12:17) One team that does a tremendous job with a particular variation of this – you know when you want something, you email support and you ask, hey, this is not doing whatever, and they’re like, yeah, we know that, it’s a limitation, we’ll fix it eventually and whatnot, and then you never know if they fixed it and you eventually forget about that.
Nikki Elbaz (12:37) Yes.
Mario Araujo (12:38) I use a tool called Spark Mail, which is an email client, similar to Superhuman, but for poor people.
Nikki Elbaz (12:41) Okay. I loved that.
Mario Araujo (12:46) I guess cheaper, but amazing user experience, built in Ukraine. And I’m like, all right, I’m just going to support these folks. So every time I send them an email with something, like, it doesn’t exist or whatever, they add it to the backlog. And the first time I did that, I was like – yeah, the backlog. I know where it is. I have one right there and I never look at it. It’s reality. When they actually – I don’t know what they do on their end, but they actually email back. I send something in three weeks or four, right now, it’s the second time it happens. They’re like, hey Mario, remember this ticket? It’s solved now. Thanks for the feedback.
