Why you should invest in visibility as a startup
As a startup, you’re in the business of disruption.
Disruption is born from seizing opportunities, moving faster than everyone else and delivering 10x improvements to the status quo. At FairFly, I found out that moving fast and delivering improvements are often directly correlated with increased visibility and openness, whether internally or externally.
This makes sense to me because I’ve realized that open source software has done the same exact thing to the tech industry. Opening up entire products down to the source code has enabled the creation of some amazing technologies and caused the whole tech industry move much, much faster. In this post I will talk about my experience and why investing in visibility can net your organization some great benefits.
TL;DR — investing in visibility both internally and externally can net your organization these benefits:
- Can help you find bugs and bottlenecks
- Can increase trust in your product and company
- Opens you to valuable feedback from customers
- Free up developer time and reduce context switching
- Make the lives of ops easier
What is internal visibility?
We all have logging infrastructure. We all have dashboards to see KPIs. What I’m talking about is taking parts and flows in the system that are currently black boxes and making them transparent. All the way through to the operations side and, possibly even to your customers.
By definition, black box components appear magical and unchangeable. As requirements evolve, internal users and even developers lose track of the inner working of them. This is dangerous because as the logic evolves we revert to using “gut feelings” and “hunches” when it comes to debugging decisions made by these components. If this is a core part of your system then you are hurting your flexibility, which can in time make you run slower or miss out on important breakthroughs.
You can identify black boxes if you have parts in your system where product or ops keep asking devs to explain why something happened, why the system made a certain decision or even ask “what if” scenarios such: “as does the code support the case of X?”, “If Y happened what would happen?”
IMO, these are an “organization smell”. Think of the time wasted here, by the person who asks and the developer who has to break context just to start reading the code and answer.
Some of you might think this should be solved by better documentation or repeating the phrase “read the manual”. This won’t work. People will always take the easiest path - grabbing someone and asking. Also documentation is not always updated.
Taking an example from FairFly…
At FairFly, one of our main products tracks prices for a flight, after purchase, and finds lower fares for the same exact flight, providing savings for organizations on their considerable travel spend. There is a module responsible for deciding if FairFly should track a flight’s price or not. At first, it was straightforward knowing why the system has decided to track a flight or not.
However, the logic grew over time to dozens of different parameters as well as machine learning elements, all meant to decide whether its logical to invest resources on tracking an itinerary. Without visibility, there is no way in hell that anyone can understand the reasoning behind any decision this module makes, let alone question its correctness.
Until recently, this lead to us spending considerable time having developers “debug” decisions, only to come up with the conclusion that it’s correct.
So what did we do here? As of right now, the module actually gathers every minor decision it made on the way to the final conclusion. These explanations are now logged and exposed in our internal admin tools, in the database and we even created reports and dashboards to view trends and alert on anomalies.
The ROI here has been amazing:
- Bugs were found without wasting dev time.
- Devs are spared from unnecessary debugging.
- Internal stakeholders got increased confidence in the system which, in turn, increased product performance and customer satisfaction.
All in all, developing this took about a day and probably saved us weeks if not more. Following this, we became more sensitive to black boxes in the system and we’re continuously improving on their visibility, gaining the same benefits described above. Usually, gaining visibility can be as easy as collecting text descriptions along the code, explaining the decisions made and exposing it in some UI.
What is external visibility?
External visibility is just as it sounds, showing as much relevant data to your customers as possible. I’m not talking about exposing your “secret sauce” nor about drowning them with information. If done right, I believe visibility and transparency can greatly increase the value of your product, its stickiness and the perceived ease of use.
Visibility makes the difference between a service you use because you couldn’t find anything better yet, to a service you will never leave because you always know what is going on and why; you trust it.
Imagine a product responsible for scheduling and running scalable jobs that convert and move data from A to B. Clearly not a trivial service. The basic and obvious solution will probably work at first… Showing a list of jobs, schedules, their statuses etc. However, these jobs fail a lot. Scale grows, schemas change, disks go full, connections fail etc. When you think of the high friction points, suddenly, this product hides a lot of relevant data, making life harder for users.
Imagine how informative you can be for your customers and how much they will love you for it. Since failed jobs are the biggest friction point in this product, you should overdeliver on visibility: Why did the job fail? Did you alert the owner? How should it be handled? If users always know what’s going on, they will trust and love the product.
Failure is not always a crash, it could be a decline in performance, some anomaly etc. Perhaps you can offer ways to improve following data from metrics. It might even be a way to up-sell.
In conclusion
As I’ve hopefully shown here, the ROI you can get from exposing information and turning “black boxes” into “white boxes” can be tremendous for the organization. At the minimum, use this article as a thought exercise for which “black boxes” you have in the organization or system and what possible ROI could you get from making them transparent. Would love to hear your thoughts about this as well.
