The product that failed because we had to scale
|Image by Ryan McGuire from Pixabay|
I worked on a new product. It failed. There are several reasons why it failed, and none of these reasons by themselves matters much. It’s rarely just one reason why anything fails. It’s more likely that a totality of decisions, actions, and inactions leads to a failure. In this case, one of the reasons in particular has been bothering me.
Although I don’t actually blame the product failure on this one reason. I kinda do. Because this one reason, I believe is a mindset we had that prevented us from being responsive. From listening to customers. From acting quickly. From taking action.
That one reason: everything we did had to be scalable.
At first read, it might seem reasonable for us to consider scale when building a software product. But for me, someone who is NOT a product manager, the conversations I had with the product team where maddening. You will see how as you read the story.
I am not arguing that I am right about scaling being the reason we failed. Or that the product team was wrong about insisting we build this product so that it can scale.
I argue neither.
I simply share this story as an example of how I failed to close the gap between an action-oriented business person who just wanted to build something that helped customers and a product team that wanted to build something properly.
It was a failure of leadership.
But for now, let’s stick with blaming the “it must scale mindset.”
The nature of the product is not important. What you need to know for this story is that it’s a self-service, freemium, SaaS product that lets a customer create and publish content for their customers. Our customer creates an account, chooses a sub-domain, myname.billsproduct.com, then uses that URL to publish content to their customers.
Great. Nothing special about this. Lots of products allow this.
In the first version of this product, we didn’t allow numbers in the sub-domain. You might think that’s a stupid over look. But…whatever. Nothing has everything. And we didn’t allow numbers.
And for a few weeks, people were signing up and no one came chose a sub-domain with a number in it. So the issue didn’t come up. No problem.
Then, of course someone tried to sign up with a number in the domain. Their website domain has the number in it, so of course they wanted to use that same name in the subdomain of our product.
When the customer got an error message at sign up, they send us a message asking why the error. This is when we discovered the “number” issue.
I asked our team to make the change to allow numbers in the sub-domain.
I was told that will take 3-4 weeks.
“THREE WEEKS?” was how I reacted.
I am not an engineer. Obviously. But I my mind, this is something that could be changed in a few minutes.
After meeting with the product manager, I learned that yes, the act of allowing numbers is a small effort. Maybe not a few minutes, but not a big deal.
That’s wasn’t the problem.
The problem was the engineers didn’t want to just make the change without thinking through the implications and downstream impacts and thinking though the best way to do it. They needed to plan ahead. Not to mention, there were other things in the sprint and in the backlog and on the roadmap that they were working on.
This is how the conversation went:
Me: I know we have a backlog and a roadmap, but this is the only request from a customer. We should do this.
Engineers: We can’t just respond to every customer request. We need a process for handling these and prioritizing. And scoping. And estimating.
Me: We are not responding to every customer request. We have one customer request.
Engineers: Today it’s one. Tomorrow it’s 97.
Me: Only today exists today. And today we only have one. What else are we working on?
Engineers: We noticed some latency in a provisioning job that will impact performance when we scale up. We’re working on a fix.
Me: We have 37 sign ups. What are we scaling up for?
Engineers: Of course, but when we get to 1,000….
Me: Let’s let that be our problem when it becomes a problem.
Engineers: We have to build things scalably. Or we’ll build up all this technical debt. And then we’ll be talking about making time to pay back that debt and of course we’ll never have time for that.
Me: True. But if we don’t address customer needs today, we won’t have any technical debt to address tomorrow because we won’t have any customers.
I didn’t get my way because I didn’t want to tell engineers how to do their jobs.
And although I say that the product failed because of our be-scalable-first-mindset, this was only a symptom of a larger problem: lack of a shared vision for why the product exists in the first place.
Where is the sweet spot between giving customers what they want and building something that’s good?