The dreaded, decelerating tugs of product debt are felt everywhere. What they dramatize, though, are mostly small, well-acknowledged, unfixed issues that pile up over time and demand iterative attention. Sometimes pretty scary, yet often manageable.
What if you were dealing with the exact opposite?
Not a bug, not a remnant of a now transitioned feature but a major part of the product; not something that’s in any way obviously problematic, perhaps even a cherished given for your SaaS category. Still, something that doesn’t move any metaphorical/real growth needle and takes away a whole lot of already strained time from the features that do.
The team at Arrows confronted (and overcame) a similar predicament.
In the following exchange, Arrows’ co-founder and CEO, Daniel Zarick (@danielzarick), writes about how they addressed this by making the alarmingly existential call of deleting a third of their product and coming away with great, freeing progress.
— How planning for their 6-week development cycle triggered this choice
— How the Arrows team validated that this was, indeed, the right thing for customers
— Notes on the actual roll-out of the transition
— “Nobody wants another inbox” and other lessons they gathered along the way
“…we had two options”
Early in 2022, we were planning our next 6-week long product development cycle and comparing our priorities.
In short, we had two options: either spend that six weeks improving the weakest part of our product (the dashboard) or spend it improving the core part of the product which is the reason people actually buy Arrows (the customer-facing checklist).
We projected that if we spent the entire six weeks improving the Arrows dashboard, at best we’d improve it somewhat. It would need a lot more work to be on par with what customers expect from other products.
And, to top it off, we didn’t believe the improvements would actually cause more prospects to become customers.
However, we were confident that if we made the customer-facing checklist better then we could build more differentiation in our product and actually convert customers.
This led to an interesting predicament: instead of just deciding not to improve the dashboard… should we actually just delete it? So we did.
And alternatively we made our HubSpot integration way better as a way to replace the dashboard’s functionality, which made Arrows way more powerful.
The only credible alternative was to have our team spend time trying to improve the dashboard. But, as with all things startups, that comes with the opportunity cost of what other things we weren’t improving instead.
So while it felt stressful at first to not improve the part of our product we felt was weakest, it became clear that it was more important to spend as much time as possible improving the core product.
Similarly, the other alternative was to just keep our dashboard as-it-was and not improve it.
But we believe that prospects judge you on what’s there just as much as what’s missing.
So if we had parts of the product that were mediocre, they’re going to possibly look for reasons not to purchase Arrows. And it was better for us to remove any of those objections from the table.
An exercise in realigning incentives
We went and surveyed all of our existing customers and started having conversations with a few trusted ones.
We asked which CRM they used and how they used Arrows in conjunction with their CRM. Then we floated the idea of removing the Arrows dashboard and eventually building deep CRM integrations instead.
These conversations gave us the confidence that most of our customers not only didn’t mind if we deleted our dashboard, they’d almost prefer it.
Because then there was a new clarity around what role Arrows played in their tool stack, and we would be incentivized to improve the experience of how they use Arrows from within the CRM (which is what they really wanted).
By removing any need to improve our own dashboard at the expense of their CRM functionality, it really aligned us and our customers.
Dealing with constraints and restricting this to new customers
Once we decided to remove the Arrows dashboard from the product, we decided to replace it with best-in-class CRM integrations that could give customers not only all the features they had in the Arrows dashboard… but more we hadn’t even built yet.
So the biggest constraint we made was to focus on a single CRM integration to prove it would be a smart shift. We chose HubSpot, for many reasons, but a nice benefit was that we used it and we had many customers and prospects who used it.
On top of that, the HubSpot API is fairly robust, but also has really nice constraints built-in. On the other hand, Salesforce’s API gives you a ton of power but with that comes a lot of possible ways to overcomplicate things and we just didn’t want that at this stage.
Since we work in 6-week development cycles, we committed to rollout out a best-in-class HubSpot integration + removing the Arrows dashboard at the end of the next dev cycle.
To make the transition smoother, we only removed the dashboard for new customers. All existing customers still have access to the dashboard they had previously… but we’re making plans to phase it out.
By removing the need to migrate existing customers, we could focus on building for the future and validating this direction without needing to worry about how existing customers might react.
The last thing we did to focus the team was to make sure a customer could replicate all functionality from the old dashboard inside HubSpot using the new integration. This gave us a clear target and way to measure our progress.
Some critical takeaways for the future
When going through this process, we had a few critical things on our mind:
1. “Red Herring” feature requests:
These are features that people ask for which, if you implemented them perfectly, wouldn’t actually make someone buy your product or use it with more frequency. They’re easy things to point out that are missing, but they aren’t core to their need. Be aware of building red herring features!
2. “Nobody wants another inbox”:
A prospect said this to us on a call and it stuck out like a sore thumb in our minds. Sometimes people talk about “software fatigue” and suggest that people have too many products and don’t want anymore.
We believe people actually desire more tooling, they just have “inbox fatigue” and don’t want more products that unnecessarily demand their attention in a new place.
Question if you can push your product’s functionality into a place where your ideal customer is already doing their job day-to-day.
3. Broad innovation vs. Narrow innovation:
Be honest with yourself and figure out if you need to build a broad innovation or a narrow innovation. A broad innovation is something like Figma or Linear, where customers have a high threshold of feature-completeness for any new product in that category.
You can win by adding all those features and making UX+design improvements to that platform, but you can’t have missing features. A narrow innovation is one where you need to do one thing superbly well, and actually having features beyond that one thing can add confusion to your product.
We initially thought Arrows was a broad innovation product, and now we realize it’s a narrow innovation.
4. “If you had to start over today, with everything you now know, what would you do?”:
We asked this question of ourselves and our team regularly. Once we realized we should make a change, we made sure that this was core to the conversation.
Just because we’d built or done something a certain way before… that didn’t matter anymore.
Our goal was to free ourselves from those constraints so we could find the best answer for the moment. Only then would we burden ourselves with figuring out a plan to actually get there. This framework was critical for helping keep us all in the right mindset.
