Every day, when I look at this elevator panel, it reminds me that even the most trivial features come with costs. The cost of one additional button may not be readily apparent. But imagine an elevator panel that includes dozens, or perhaps hundreds, of specialized buttons. A panel like this might be completely counter-intuitive and maybe even unusable.
Knowing what I know about the dog run button’s purpose, I’m sure that it’s exactly where it needs to be. However, I often wonder about the thought process that went into its design:
- What need was this feature designed to address?
- Was that need worth addressing?
- If so, is this the optimal implementation?
These are the same questions we ask as we strive to innovate ADL
in a way that achieves extraordinary flexibility, yet keeps it slick—both above and below the hood. As the fastest-growing product at TT, ADL has garnered more than 100 enhancement ideas from its users; the innovation that surrounds ADL is truly remarkable.
Below, I’ll shed some light on how we analyze enhancement requests, especially in the context of the three questions mentioned above. My reason for doing this is simple: I want to reassure users that their suggestions don’t disappear into a void. I also want to encourage users to continue to participate in the brainstorm and help us keep the pace of innovation on fire.
The Root Issue
When we visit a doctor, we don’t typically start by handing him or her a list of the prescription drugs we need; the doctor usually makes a diagnosis first.
In the same manner, when a product enhancement is suggested, we don’t usually jump to implementation. Instead, we examine the root issue first.
We typically find that each enhancement request is actually a request for a solution to an issue encountered by the user. An examination often reveals the root issue to be one of the following:
- A defect that needs to be fixed
- A need that the user doesn’t know the product already addresses
- A need that the product doesn’t address
Here’s a real example. During the beta phase of ADL, a user suggested that we introduce the ability to automatically launch an algorithm when the market opens. Upon further interview, we discovered that the user had previously attempted to launch his algo during the pre-open, only to have it pause immediately. As a result, he resorted to manually launching his algo right at the open to gain place-in-queue, and he was looking to automate this manual action.
The root issue here was that all algos were designed to pause during untradable market states (e.g. closed, closing auction, expired, post trading, freeze etc.). What the trader really needed was a way to operate an algo outside of tradable market states. To satisfy this need, we ended up introducing the “Ignore Market State” functionality and the Market State Block.
This was a case where we decided to address the trader’s need. However, that is not always the case – every identified need begs the question: “Is the need worth addressing?”
Scope of the Product
When it comes to determining whether an identified need should fall within the scope of the product, I believe in the “less is more” philosophy. I strive to keep ADL focused on and proficient at its core competencies: market-depth-based analysis and execution.
Some users may conclude that their business needs lie outside of ADL’s scope. I recognize and respect this decision. In fact, I believe focused scope benefits the prospective user; the more focused the product, the easier it is for a user to determine whether or not a product meets his/her needs.
When ADL fits a user’s needs, its focused scope translates into a superior user experience with a product that is highly performant, intuitive and effective.
As ADL matures, we plan to gradually expand the scope to accommodate the usage of technical indicators and fundamental data. However, proficiency will always be prioritized before expansion.
Implementation: Tools, Not Options
Once we determine that a need falls within the scope of the product, we look for a solution.
The core “less is more” principle behind ADL’s implementation is self-evident in the product itself: ADL is a streamlined toolbox of blocks, not a giant collection of checkboxes and drop-down menus.
Look at the image below. I call this the “learning curve vs. flexibility” spectrum. Generally speaking, hard-coded options, such as drop-down menus and checkboxes, lie on the left; they are probably the easiest to use, but also limited in flexibility. APIs are placed on the right; they probably have steep learning curves, but are also very flexible.
|Learning Curve vs. Flexibility
ADL’s implementation is deftly balanced about halfway between. It does not require the user to write code, but it does grant sufficient flexibility to excel at its core competencies.
When this principle is applied, the final implementation may end up looking nothing like the original enhancement request, even if it fully addresses the user’s need.
Back to Dog Run…
To come back to where I started, let me tell you what the dog run button does: it calls elevator car #1, which stops at the second floor, where there is an indoor area for walking dogs. Other cars don’t stop at the second floor.
Applying the principles mentioned above, it seems that this button was a downstream effect of an architectural limitation (apparently only one elevator can stop at the second floor) combined with the residents’ need to use the elevator to reach the second floor (apparently residents can’t or won’t use the stairs). Going further upstream, the root cause seems to be the residents’ need to walk their dogs indoors. I don’t own any pets, but it is my humble opinion that owners should walk their dogs outside in the first place…yes, even during Chicago winters. With that said, the indoor area seems like a superfluous feature that can be removed along with the “Dog Run” button.
While I hope I entertained you with my analysis of the dog run button, I hope even more that you gained an understanding of how your ideas and feedback fuel the processes that drive ADL’s evolution. If you’re an ADL user, I hope I’ve inspired you to contribute (or continue contributing) to the innovation of ADL.