How we approached building a startup at an enterprise 

What is our enterprise startup?

Vidcast is an asynchronous video messaging application we launched last August as the first startup in the Webex Leap accelerator program. Over the past year, Vidcast has seen triple-digit growth quarter over quarter. The Vidcast team has also launched 40+ new features, garnering raving fans along the way. As companies around the world, including Cisco, increasingly embrace hybrid work, it’s no surprise asynchronous video is seeing explosive growth, due in part to its ability to combat meeting fatigue.

Focus on leveraging technologies vs building your own

While building Vidcast we often ran into this dilemma about different components which were often not core to what we were trying to do, whether we should build it ourselves or should we try to leverage something which already exists in Webex. Our principle is to always try to minimize the surface area we own which is not related to the core of our product and leverage as much as possible.

A lot of times, things that already exist were not meant to be used by other applications or for different use cases, and so require further work and dependency on another team to make it flexible for our use case, which is not a fast process as every team has their priorities and goals and they all are working towards delivering the things they committed.

Having a startup mindset, we often just want to move fast, and be in control of our destiny. Being a startup in an enterprise, We needed to approach this slightly differently, we needed to find a balance of running fast but also not building everything ourselves or custom/different. As eventually once things work well, we also want the product to behave nicely in the ecosystem and want to keep the number of things for our team to worry about to always a minimum as we grow.

We had this dilemma when we were deciding which identity solution to pick for our product: should we go DIY or leverage Webex identity or use a 3rd party? We knew that eventually we would want the product to play nicely in the Webex ecosystem so going with a 3rd party provider would have limitations as then it would restrict the customizations or migrations we can do. Building a DIY vs leveraging Webex identity was a conversation where we continuously went back and forth on, as building a DIY allowed us to launch a solution faster but then increased the effort around security and connecting it to the rest of the ecosystem later whereas leveraging Webex identity required customization effort from other teams internally which already had their priorities which would delay our target release date. We eventually decided to leverage the Webex identity with the delay needed to build a more connected experience for our users and reduce the tech debt for our team.

There are cases where we didn’t go this route also, one such case was when we implemented the feature which allowed a user to import a Webex meeting recording to Vidcast making it easier to share and consume, we decided to create a copy of the asset instead of leveraging the original asset as we felt it was more important to have consistent streaming experience across Vidcast where a user gets the same experience when streaming a Vidcast imported from Webex or recorded on the Vidcast platform itself.

It’s easier to ask for help

When we are building a new product, we often are scrambling with a lot of technical questions and unknowns and don’t usually have the expertise in every domain we are trying to build for. When starting a new startup, sometimes we might reach out to open communities asking for help, usually without offering anything in return and also being careful of the information we can share externally. Being at a big company, it does provide us with the privilege to have a massive community available internally to us with whom we can share our problem/challenges more openly and all of them are also incentivized to help as at the end of the day if the product does well, it will impact all at the company positively. When we were building Vidcast, we oftentimes ran into such scenarios, for example one of them was for how we approach video streaming, having access to the internal Webex community which already had solved this problem before for other use cases made it easier for us to navigate it and deliver a good solution sooner.

We have multiple people from different teams helping Vidcast and contributing time to it outside their regular day to day tasks as it’s something they are excited to help build

Be open to taking the unexpected path or the path less taken

At a SaaS enterprise, a lot of the internal services are not designed at the start to be used by other services and so the APIs are built with a particular client and context in mind, but at the same time they end up exposing some public endpoints with a lot way to use them but with some limitations as they are usually intended for end customers and partners.

Our principle is to build something people like first then figure out how to optimize it later..

At Vidcast, we oftentimes decided to go with the public APIs for internal Webex services as they were sufficient for our use case even though Vidcast being a first-party app, just so we can move faster and get the value out to our users sooner.

A few instances where we took this approach were when we implemented the feature to share a Vidcast to a Webex space or to import an existing Webex meeting recording, where the public APIs were already rich enough with all the possible information we could need so it made it a no brainer for us.

What’s one thing you cannot take lightly even being a startup at an enterprise: security

One thing we were very clear about from the moment we started the journey of Vidcast at cisco was to never compromise on security and think of security first always. This is where we differentiate from the path a lot of startups follow. As in a normal startup with limited resources, the focus is on figuring out the product fit more than scale or security. Being a Cisco product, people always associate our product with security so we always have to make sure we deliver on that irrespective of the scenario. Due to this when we started building Vidcast, at every step we always asked ourselves, is it secure enough for our users or can we do better? if we can do better then let’s do that.

For more Webex integrations, check out:

• Slido in Webex: The integration that’s got everyone talking
• Less Work, More Leads: New Webex Integrations with Eloqua and Salesforce
• Cisco and Google join forces to transform the future of hybrid work