Minimizing time to value
When Recharge got started, the founders picked their initial projects by reading Shopify app store reviews, identifying common trends in negative reviews, and shipping products that aligned with those reviews. Eight years later, that's still fairly common practice for how we identify features to go build. We look at feedback from our largest merchants, periodically analyze support tickets and reviews, and shape our roadmap accordingly.
Agile, Lean, and the various iterative development frameworks would nod approvingly at this approach. I think all those frameworks are missing something: the level of effort. Recharge was bootstrapped for the first six years of its existence, and that informed how we think about level of effort. When you need cash now to pay your team, you don't have the flexibility to take people off the board for six months in an investment effort. Customers want stuff yesterday or they're going to a competitor.
We have an adaptive framework that we use to prioritize our work.
- If there is a low effort improvement to be made with clear and obvious benefit to the customer, go do that.
- If there is not a clear and obvious, low effort improvement, take a pause and go investigate to find something.
- If nothing turns up, and there is a high effort improvement with clear and obvious benefit, go do that.
- If there is nothing there, go do more investigation.
- The second worst thing to be doing is a small effort that is ultimately useless.
- The worst thing to be doing is a large effort that is ultimately useless.
We are heavily biased towards small, incremental improvements, and incredibly shy of larger efforts. Our experience has been that if something is well-understood, it is typically easy to break into small, incremental improvements, and if something is hard and nebulous, it carries a much larger risk of failure. That's rarely a risk we're willing to tolerate.
So how do we deal with the problem when we absolutely must make some monumental change? We recently had to deal with this exact scenario with our Flows product. In 2017, we built a basic workflow engine that allowed for simple actions on database objects using a GUI. In late 2022, we started researching ways to expand upon it. We kept hitting walls. Code that hadn't been updated in five years no longer really worked in our current paradigms. There were all sorts of ORM dependencies that throttled the database. It was nightmare code.
We were all getting the feeling that we were going to have to undertake a massive rewrite, but that would take at least a month where we weren't adding value to customers. And we hate that. So we took two more weeks trying to find some way to untangle the knot. Still couldn't. Finally we had to bite the bullet and do a ground-up rewrite.
When we did the rewrite, though, our understanding of the problem space was considerably better than it was because we had bashed our heads against the old code for so long. We were able to quickly sketch out the bones of what we wanted. We were able to get to customer value within six weeks.
That philosophical focus on low effort projects that get to value quickly is the key. It focuses us away from burning time on useless features and rewrites that crush our engineering team. It's how we win.