Author: abhiyerra

1. Capabilities
2. Offerings
3. Teams
   1. Core
   2. Vertical

As we grow into our partnership based approach we need to ensure that context switching is reduced and we can dive deep into our DevOps, DataOps, and IT capabilities. The approach we should take is to hire decentralized general managers/technical managers to run each vertical who report to a Business Development or Engineering & Distribution.

This is based on Amazon’s two-pizza/single-threaded teams. By having decentralized teams completely focused on a singular objective leads to higher throughput as each team can focus on a singular vertical or product. Further, having a team with autonomy can lead to faster problem discovery for a particular vertical allowing us to create additional solutions and products.

Capabilities

opsZero is an engineering company, our products and solutions provide technical solutions and products. Our core capabilities are DevOps, DataOps, and IT which are the three things we want expand into across industries and verticals. To do so effectively we need to focus on three fundamental things:

• Capital. Ensure we are financially sound and continuously improve our rate of return and cash flows. We continuously generating additional value from our customers by getting more and more deeply integrated into their Cloud Infrastructure.
• Partnerships. Use a top down approach to build partnerships with companies serving specific verticals who we can complement with our capabilities to launch new solutions. These solutions are not grouping of opsZero products and services with our partners solutions.
• Engineering & Distribution. Use a bottom up approach by building products for engineers and other technical contributors. These products are APIs, Extensions, and Datasets. Use Cloud marketplaces for distribution to reach these technical audiences.

Offerings

• Solutions. Solutions are industry specific combinations of capabilities and partnerships. These are sold as a contract to companies. For example, opsZero CMMC would be a Solution as we are partnering with Meerkat, XQ, and using our IT capabilities.
• Products. Products are self-serve and targeted toward technical buyers. For example, opsZero Kubespot would be a product as it is a collection of modules that are used together to perform a task. opsZero OMYAC would be a product because it is self-serve, industry agnostic, and built for a technical audience.

Teams

To allow us to move quickly we should split the company into two groups:

• Core. The leadership team that builds and manages the common tooling and best practices for the company. The core team should be exceedingly small. This team has the yes/no for launching new solutions and products based on market data.
• Verticals. Products and Solutions are assigned single-threaded general managers. The general manager will be given the best practices provided by the Core team and will be responsible for growing the P&L.

The Product Teams financials are tracked and the return on investment is measured to ensure bad bets are shutdown and good bets are rewarded.

Core

The core team should be small and should make decisions quickly with the following roles:

• CEO. Yes/No on Capital Allocation decisions.
  • Finance. Manage capital, finance and taxes.
• VP of Business Development. Build the core partnerships of the company and figuring out the companies to partner with to build new Solutions.
  • Sales, Marketing, Design. Website, Branding, and Sales collateral.
• VP of Engineering & Distribution. Product development and cloud marketplace distribution.

Vertical

The Vertical Teams act as mini-startups focused on building and scaling their solution or product.

• The team lead is the General Manager for solutions and they report to the VP of Business Development. When we are selling a Solution it is important that the General Manager is knowledgable about the industry we are selling to the solution to and it is why they are the lead.
• The team lead is the Technical Manager for products and they reports to the VP of Engineering & Distribution for products. When we are building products the products are technical and require understanding of the Cloud so we need the products to be lead by a Technical Manager.

The units act independently to grow the business while working within the opsZero common infrastructure. The units have the following roles with additional roles based on the needs of the vertical.

• General Manager. Responsible for growing the P&L of the unit and work to build the sales and marketing needed. Usually, they should have experience in the industry they are selling to.
• Technical Manager. Responsible for delivering the product or solution. For a product also act as the lead to ensure that the product is built and delivered and new features are added.
• Programmers, Support, etc. Any additional people that need to be supported with the idea that they are two pizza teams.

opsZero is currently a services company where we provide DevOps. While this is a good market to be in there is a natural limit to the scale of what load we can take with DevOps without completely burning out. It is just the nature of services and DevOps.

However, services provide us a lot of insight into how companies behave concerning their infrastructure so we need to provide services indefinitely. However, because there is an upper tier to services we will also build microsaas products. These products will be tiny. They would be considered features of other companies. We will target specific niches with our products and build and distribute them within a week. These products are those that are technically hard but provide immense value using our Cloud expertise.

As we build out these microsaas products and services, opsZero will become a marketplace for Cloud Infrastructure related Products and Services with the eventual goal of opening it up for others to release on top. The goal we have now is to build out and dogfood this platform internally and build partnerships that can also launch on top of this platform.

As we are starting to grow our business with both services and products the problem is now on effective marketing. The choice I want to make is to focus on building our Django based app. While it is true that marketing sites are usually separate from app sites I do not think it applies to us.

opsZero’s goal is to rapidly release new products with streamlined content templates, documentation, and APIs all within the same application. Combining the entire end to end of app creation, app marketing, and app distribution into a single location.

If someone visits any site on opsZero, we will have the same page layouts with almost no differentiation between each. It should be as if you were going to the App Store to purchase an app. We are selling products, services, and packages for different verticals.

While I understand there may be a frustration in not using something like WordPress I think having a unified distribution engine is more important and we can customize the CMS to what we want it to be.

One of the things I want us to stop doing is ads. If we spend a $1 on an ad that $1 is lost forever. If we spend a $1 on a product and launch that we control that $1 and can repurpose that product. I’d rather we spend $1000/month on building various Vertical Market Software that takes less than a day to build and launch those on LinkedIn, Hacker News, etc. We then use those to do more effective email marketing since we will then have soft leads.

The steps are as follows:

1. Launch a Vertical Market Software on a weekly cadence. These are single purpose apps that take less than a day to build including calculators, datasets, and products. These products should provide a single Job to Be Done and repurpose existing code as opposed to creating brand new code. Further, these apps have a single marketing page either on its own domain or on *.opszero.com powered by System6. The product should offer a free version and a paid version to collect warm leads that we will add onto our CRM.
2. Every week we promote these products on various places including LinkedIN, Hacker News, LinkedIn, AWS Marketplace, etc. We either do it ourselves or hire a freelancer to do it.
3. We collect the emails that result from the launch and outreach to close the companies on the bigger opsZero services plans. If we generate revenue on the products that is also a benefit.
4. Repeat.

The idea behind these is velocity. We are not trying to be perfect, we are not trying to cover everything, and we are trying to be as small as possible to build the product within 8 hours. Furthermore, having multiple products that are named differently but providing the same functionality and different marketing is also fine as we may be targeting various verticals.

opsZero builds Vertical Market Software, modeled after Constellation Software and Tiny, but focusing almost completely on Cloud Infrastructure and APIs. Our goal is to combine different systems together into a coherent whole and sell those as easy to use APIs with minimal to no UX. The Vertical Market Software route is not unique and there are many companies that do it.

• Constellation Software: They focus on mission critical business software that is hard to replace like bowling alley software. Public and Private sector with companies they build maxing out at about $5 million in revenue.
• Tiny: They build and buy various companies including software focused on designers.
• Jack Henry: Build software for credit unions and small banks. Expanded by buying smaller firms.
• Tyler Technologies: Build software for public sector.
• Oracle: Build and acquire enterprise software.

opsZero is pursuing a slightly different approach to play to our strengths as opposed to the companies above. Our goal is to build Cloud Infrastructure tools and services for various niches and do so with almost no frontends instead focused on APIs, datasets, and extensions targeting Cloud Infrastructure. Building admin sites, marketing content, and other UX related things are not something we really want to deal with and we just want to leverage the plug-in ecosystem that third parties provide.

Our strategy for niches is to go after a vertical then develop a platform business providing Cloud Infrastructure. We attempt to make our initial foray small and with outside expertise as we may not understand that vertical ourselves. Once we have done that and have created moats we expand our moats based on the needs of the customer.

Lastly, we build on top of a monolith allowing us to quickly launch new business verticals with little fanfare. As such acquisitions are likely out of the picture and we choose to build our products ourselves. We may focus on acquisitions to grow in the future but we are builders not buyers.

I’ve been deliberating the optimal approach for product releases, whether as a single brand within opsZero or as multiple brands. The choice of multiple brands appears logical when selling products where appification has resulted in a one-product, one-purpose generalization. However, for services, a brand that offers a diverse range of offerings seems more effective.

1. In the realm of products, where both individuals and companies are well-versed in apps, having a single app dedicated to a specific function seems to be an effective strategy for gaining customers instead of overwhelming the customer with multiple choices. For instance, even AWS primarily features a handful of frequently used services with numerous other apps in a supporting or complementary role.
2. Customers seeking a specific function will find it easier to locate a product that precisely fulfills their requirements. This approach allows us to tailor products to various niches, even if the core product remains the same. So we can sell multiple products to multiple niches.
3. Leveraging the same foundation, we can target multiple niche markets and generate multiple service endpoints.

Potential drawbacks of this approach include:

– The possibility of receiving a higher volume of quality leads through a single domain.
– Potential cost implications related to managing multiple brand names.
– The necessity of overseeing and marketing multiple brands.