Arjun (my son) sat next to me at my desk. He was a bit nervous but we had practiced 3 times before he was ‘on stage’ in front of hundreds of people and the zoom meeting turned to him. My ten year old began to demonstrate how to deploy an Operational Database in AWS, showcasing how auto-scaling worked and how to set up replication. All of the sales team and my colleagues were quite impressed with him, and I am very proud of him. For my team, they got to see first hand what I had been saying for years.
During the development of Operational Database and Replication Manager, I kept telling folks across the team it has to be “so simple that a 10 year old can demo it”. No one took me seriously… until that moment during an internal sales kick-off meeting.
“so simple that a 10 year old can demo it”
Watch this:
It is hard for an enterprise infrastructure software company to create simple products. Yet, users of those products want a consumer level of simplicity in enterprise software. Unlocking product led growth depends on an easy-to-use, self-explanatory interface.
As a product manager, I rank features in my backlog against:
- How much revenue will this help me get?
- How hard is it for engineering to build?
- What is the impact on my support costs?
- What is the level of competitive differentiation this provides?
From an engineering perspective, we look to add the features that customers want over time, baking in a tremendous amount of flexibility to support extensions to the product that a small portion of customers value. In aggregate, this flexibility at the expense of ease-of-use for the “general user.”
Simplicity on the other hand often argues that we need to “take features away”, undoing a lot of the things that were hard fought for earlier. It is hard to predict the impact of simplicity on revenue, harder yet for engineering to build it (we call it “automation”), impossible to understand support costs and while it creates a clear competitive differentiation, it is hard to quantify. Further, how do you measure progress and convey to engineering that they are making progress? When is the said progress sufficient?
The courage it takes to remove features is very challenging for all of us. It is a necessary cost to unlock a future where the average business user can get the full value from our Cloudera Data Platform by matching UX with their worldview and workflow. As an engineering culture we always want to provide unlimited flexibility to open up a world of opportunity. Yet the business user is here to just accomplish a few goals that we can help them with. Removing any friction that gets in the way of those goals is our objective. Listening to our users is the key to knowing exactly what to remove, what to promote to the top, and what to innovate on.
I began on this journey at a previous employer where I was responsible among other things for portfolio strategy — where I had to come up with a way to quantify simplicity. We spent a summer benchmarking “easy to use” competitors in terms of
- # of clicks to set up their product,
- # of keystrokes required on a keyboard
- the time it took to deploy their software end-to-end.
I took this data to my peers and their PM teams and got a lot of strange looks. The most common feedback I got was that product management had never installed our own products… and so they had no way to digest this information. It took a year to get the teams to agree to invest in simplification and another year to start quantifying the complexity of our installation process. In three years, we started the process to automate and simplify our setup.
There is so much we cannot measure about the impact of a user experience. We can’t measure the little smile a product can put on someone’s face. We can’t measure what it’s like for someone when the interface gets out of the way and people can just quickly get done what they came here to do.
Fast forward to Cloudera, I had an opportunity to re-imagine our operational database and replication offerings for public cloud. We had long meetings about what it meant and ultimately decided on a mission to deliver an “autonomous database” which demanded a clean & minimalist UI… if we continued to expose the nuts and bolts like in the legacy versions, it would violate our core product value i.e., that it was an “autonomous database.”
Cloudera HBase configuration from Cloudera Manager
Cloudera Operational Database in CDP Public Cloud:
The first challenge — we had to go from a deployment process that had tons of options and decision points to one that had 1 option and no configuration decisions. We had to identify the “optimal path” for customers without any information from the customer. This meant intelligent automation behind the scenes. To make matters worse , our first major new feature was “auto-scaling” and we couldn’t have a button or ask for input. We also couldn’t reference the underlying infrastructure as it would break our abstraction as an “autonomous database.”
More recently, we have been working on integrating HBase’s rich replication capabilities into Replication Manager. The requirement was “simple” — support all forms of HBase replication across CDP Private Cloud Base, CDP Public Cloud DataHub and CDP Operational Database Experience. But when is simple, simple enough?
Our first step was to capture and automate all the steps to:
- Eliminate the need for x-kerberos realm authentication (which meant deploying OpDB Replication plugin)
- Setup replication peering between two OpDB clusters using a combination of command-line and/or CM configurations (involves rebooting the clusters)
- Create a snapshot
- Export the snapshot to the destination in the Cloud
- Import the snapshot into the database
- Enable replication
To do this, customers had to follow our documentation and many chose to hire Cloudera professional services to implement this.
As you can see from the demo video, most of this was already in Replication Manager by the time Arjun did his demo. The team, at this point felt that the product was GA ready and the amount of simplification was dramatic compared to what was required up to that point.
However, Arjun got hung up on the remaining manual steps…specifically:
and
So, at the end of the demo, I refused to let the product GA. Despite all the improvements that had gone into it, the workflow was still too complex and my son struggled with setting it up. In fact, he simply didn’t know what to do with these manual steps and we glossed over them in the demo.
Since February, the team has continued to work on eliminating these manual steps and is ready to release the capability generally available once again.
Current GA candidate for HBase replication in Replication Manager
But I need another 10 year old on the team to step up and let us know that our product is ready to go as Arjun is now 11.
If you are interested in trying out CDP Public Cloud and the Operational Database, try out our Test Drive.
Editor's Choice
