Life is like a hurricane here at Duckbill.
In February 2020, we began building what would become DuckTools, a new AWS cost management SaaS tool, modeled off of our extensive internal tools we built for our consulting projects. We launched to the world in private beta in December 2020.
This month, we shuttered it.
Let’s talk about why.
Race cars, lasers, aeroplanes
Like many great products, DuckTools began as a set of internal tools.
The Duckbill Group, being a highly technical consultancy, had built and contracted a number of clever scripts and apps to help us deliver on our mission: lowering the horrifying AWS bill. While our Cloud Economists are able to help almost any company reduce their bill, our consulting services are often not cost-effective for a company with, say, $50k/month in AWS spend.
That got us thinking: What if we turned our internal tools into a public product so we could help people our consulting services weren’t a fit for? We could expand our market, help more people, build a passive revenue stream, and perhaps even create an upsell path to our consulting services.
We knew we couldn’t compete directly with existing cloud tools built by large teams with their mountains of venture funding—nor did we want to. Our vision was a set of small, focused tools to help people answer very specific questions—like “what Savings Plan should I buy,” “which DynamoDB capacity model is best for this workload,” or “where’s all this Lambda spend coming from and what can I do about it?”
DuckTools!
I joined Duckbill as the Lead Product Engineer to make this happen and bring a new product to market. It was always a risky proposition; this was effectively a brand-new startup (albeit, within a stable company), and common wisdom says most startups fail.
We believed we had some unique advantages, though: a deep pool of technical knowledge in our Cloud Economists, a pile of consulting customers eager to tell us about their problems and test our early ideas, and powerful existing internal tools to build off of.
I spent my first few months developing and executing on a pretty simple plan: Let’s take a few of these existing tools and wrap them in a nice-looking app with all the standard trappings of SaaS: auth, a dashboard, team management, that sort of thing. We’d get some beta users from our existing clients, get some feedback, and start adding more tools based on what people ask for.
It’s a Duck-blur
The original go-to-market plan involved leveraging our existing consulting sales conversations to also pitch DuckTools. We figured that anyone with the kinds of AWS cost challenges The Duckbill Group solves would also be interested in cost tooling. Given we already had existing lead flow, sales processes, and sales staff for our consulting, we thought this would make for a strong advantage.
As it turned out, this plan fell flat on its face for a few reasons:
- The cadence of these sales conversations was much slower than what we’d need for DuckTools. You need to talk to a lot more potential customers when you’re selling three-figure SaaS subscriptions than when you’re selling five- and six-figure consulting engagements.
- We hadn’t considered the incentives for our sales staff. Why spend any time talking about a sub-$5,000 TCV deal when you can talk about a $100,000 TCV deal instead? Our sales staff rightly focused on the higher-leverage deals. Spending any time selling DuckTools was, at best, a distraction.
- What we really needed was product feedback—not a whole bunch of paying customers. Of course, we wanted both. Given the choice, the former was much more important. But our sales staff was more concerned with closing deals than getting beta users—again, rightly so.
- Our existing customers just weren’t that interested in DuckTools. “Why would we want a tool when we could just have The Duckbill Group handle it for us?” we’d hear. Ruh-roh.
Despite those problems, we thought that we’d at least get one or two beta customers if we gave it enough time. So we kept at it for a few months longer. Foreshadowing intensifies.
D-d-d-danger
By fall of 2020, we still hadn’t seen much interest in buying DuckTools from the people we were talking to.
This was becoming a serious problem.
As any product manager will tell you, building software without talking to customers is a recipe for disaster. As product owner, I needed to be talking directly to the people we were trying to sell to a lot more than I was
Since we can’t (or, at least, really shouldn’t) build a product in a vacuum, we came up with a new plan to rapidly get user feedback: We’d launch!
In December 2020, we put out a barebones marketing site with some demo videos of what we had built so far and a request for customer research interviews. We kept the launch pretty low-key, afraid of being inundated with more interviews than we could handle. This turned out to be a good idea. Ducktools.com was born and it worked fabulously; dozens of helpful, interesting, and good-looking people volunteered to tell me about their cloud cost problems.
I poured over hours of notes and call recordings, condensed my findings, and came to a few sobering conclusions:
- What we’d built, people don’t need. Or rather, they don’t need it enough. We’d built a really nifty Savings Plan calculator that solved a problem for a number of customers. Unfortunately, that number multiplied by what people were willing to pay for it didn’t equal a sustainable business any time soon.
- What people want, we can’t build. When we asked what people struggled with, they described a variety of AWS cost pain points we were all-too-familiar with: forecasting spend, tagging, periodic reporting, unit economic analysis, and many more higher-order problems. Each of these could be their own full-fledged product (and some are!), but none of them we felt we could do well with our resources. We joked internally that many people really just wanted Cloudability or CloudHealth but at a fraction of the price.
- What customers want diverges significantly from the specialized tools our Cloud Economists need. We’d hoped to offset the engineering cost of building DuckTools by making it do double-duty as internal tools as well. That clearly wasn’t going to work now.
What to do, just grab on to some…
While the result of our research was concerning, we could still perhaps resolve it.
Could we try to find more of the few customers that wanted what we had already built? It’s possible, but the math just didn’t add up. Plus, we expect AWS to improve their own tools such that ours become obsolete within a couple years—faster than we could recoup the investment.
Could we hunker down and build the heavyweight solutions people were asking for? It’d be expensive and tricky. We could hire a team and make it happen. But where would we get the money for all that hiring?
And so, we ran face-first into the wall of Company Strategy.
We’re a bootstrapped company and proud of it—it lets us build the kind of place we want to work. Being profitable and having positive cash flow is of the utmost importance to us. Spending “a team of engineers” money on a product that won’t see ramen-profitability for two-to-five years doesn’t fit well with that model.
And further, the more investment we make into that path, the more of a distraction it creates from our two other lines of business—our consulting and our media publications—which are both profitable and growing steadily.
Bad and good luck tales
It’s always worth considering what we could have done better.
These are the lessons I learned; maybe they’ll help some other product builder out there:
- Talk to more customers and do it much earlier. This is the advice in big bold letters on every product book I’ve read, but I still didn’t do it enough. If I’d had the conversations I had in December in July, we would have realized the market fit we were hoping for didn’t actually exist.
- When starting a new business, you need to do sales yourself. “I’ll build it and someone else will make sure it gets sold” is a recipe for a big disconnect between Sales and Product. I needed to be pitching to customers and hearing their responses directly. But I thought we could achieve better results by separating them.
- Figure out how much of a problem you’re solving earlier on. Plenty of people told me that our Savings Plan Calculator solved a pain point they had. But it wasn’t until we started digging into how much they’d pay for it that we realized it wasn’t viable as a standalone product. The products you build to solve a $100/month problem and a $1,000/month problem are not the same.
These aren’t particularly new insights. I could probably find a chapter matching each somewhere on my “how to build product” bookshelf.
As usual, though, experience is the best teacher.
Tales of Derring-do
While it wasn’t an easy decision, we realized we didn’t really have a choice.
We had to close down DuckTools as a public-facing SaaS. It’s a good product and we’re proud of it. But the market for it isn’t what we hoped and the path to making it viable doesn’t fit our business goals or the resources we have.
While I’m definitely sad to see DuckTools go, parts of it will live on as internal tools. If you took some time out of your day to take a customer research call with me, thank you! Your input was invaluable.
And if your AWS bill is still horrifying, The Duckbill Group will always be here to help.
— Kevin Kuchta, Lead Product Engineer, DuckTools
