Tag: opszero

Currently, System6 has a single customer model that links to all the products. This customer model is tied to the Lead in Close CRM. Unfortunately, I’ve found this centralized Customer object a bit difficult to scale past services. We may have 100s of customers for a product but only a couple dozen for services.

To alleviate this problem each product will have its own customer and will be loosely tied to the Close CRM Lead. This results in each product being built as a silo with its own PnL.

An additional benefit of this is we are becoming “microservices” in that each app in Django acts as a microservice with very small scope to make it easy to test and maintain.

While we can do Azure and GCP we are much slower at accomplishing tasks on those Clouds versus AWS. So we should deprecate GCP and Azure for the services we provide for opsZero and only provide them insofar as we do migrations from GCP and Azure to AWS.

Azure and GCP have completely different models for how they handle IAM which is 90% of the difficult of managing the Cloud. Even if we can get the resources up in a repeatable manner using Terraform, the access control has been the most difficult to maintain. While one can say AWS IAM is also complex, we have experience with how it works so can debug it much easier than Azure or GCP.

Division of energy. Trying to make AWS work well and integrating our products to work with AWS well is a better ROI than trying to build for Azure and GCP. Or if we do provide resources within those Clouds we should run resources in them as opsZero and provide an API for customers to use. By focusing on AWS we can reduce costs and deliver faster. This should be like how Southwest only uses 737s. It brings down the cost to hire, and increases delivery velocity.

Migrations to AWS are okay. We should be okay with migrating companies to AWS from Azure and GCP. We just treat those Clouds as legacy and do the migrations.

We will get deeper into AWS and will not build tooling for Azure or GCP.

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.

> Results are gained by exploiting opportunities, not by solving problems. – Peter Drucker

We have been approaching marketing, sales, and product disjointedly. One of us is doing product and services and one of us is doing sales and marketing. We are not working as a unit to attack a common goal. Our core solutions are Cybersecurity, DevOps, DataOps, FinOps, IT Modernization & Management, and Workflows & AI. While having these as our solutions is great we do not have a clear attack strategy. We are disjointed in terms of how we are attacking the market as we are taking a shotgun approach.

While we have built products to support our solutions they are not advertised or promoted even though they are open source, solve problems cheaply, or could be great mechanisms for getting inbound leads. This seems to be a huge waste as we have a lot of resources that could benefit from wider exposure. We need to change this so that the entire company can work as a unit, even those providing services to help generate additional sales. What we should do is a comprehensive deployment of marketing and sales that involves distribution along with the product or capability we are gathering.

Since our solutions are applicable to such a broad market we need to subdivide the market into the smallest niches, the leafs of the tree, and build products or launch capabilities speaking to to those specific markets. Once released we should coordinate content, ads, social media, email, and distribution on third party channels all at once as to get a big targetted attack as opposed to doing a cluster bomb approach. Targetted attacks also have a higher ROI as opposed to a cluster bomb approach.

The steps for this should be the following:

1. Figure out a tiny subniche in the larger industries we are targeting. Say we talk specifically to the Secretary of Labor and their underlings in states with less than 5 million people.
2. Collect the data of the people we want to reach.
3. Build a niche product including calculator, API, datasets, etc. that would help them day to day. Some of the things we build we will collect payments for and others we will give away to collect leads to follow up.
4. Build a marketing site on opszero.com/ that talks to the needs of that group.
5. Setup ads focused on outreach to that group with Google Ads, Microsoft Ads and possibly Twitter and Reddit Ads.
6. Setup AWS Marketplace and Azure Marketplace offerings of the same product to get larger distribution and inbounds.
7. Setup a sales email outreach for that group.
8. Update the core proposals, contracts, legal that we send when we are closing the contracts.
9. Collect and close the sales.

From the moment a potential customer contacts us, we treat them as a valued customer, regardless of whether they have given us any money. This approach aligns with our primary work principle: Customer First. Our success depends on being the best alternative available to the customer. Given the numerous options at their disposal, it is crucial that we provide exceptional service from the moment they engage with us.

When a prospective customer reaches out, we commit to doing everything possible to help them succeed and to act in their best interest. We earn their business by diligently answering questions, consistently following up to stay top of mind, offering guidance throughout their decision-making process (even if it leads them to choose another provider), and working to build trust. Our business model relies on trust, which must be earned rather than simply granted. To entrust us with something as sensitive as their cloud infrastructure, customers need to know that we are their partners from the very beginning.

We may not always secure a customer, and frankly, we do not aim to convert every prospect. However, by conscientiously sharing our expertise, we also improve ourselves by gaining valuable information to enhance our own [capabilities](https://abhiyerra.com/notes/capability-based-growth/).

Keep the following guidelines in mind:

1. Follow up continuously. Touch base after meetings and a few days later with open-ended questions. Maintain regular communication so the prospect has us top of mind. Simple messages, such as “Just following up to see if you have any additional questions?” can be effective. We should never let more than half a week pass without communication.
2. If a prospect needs more time, offer assistance with their decision-making process. Much of our work is specialized and carries long-term consequences, so we must find ways to guide potential customers in their decisions. Whether it involves connecting them with our existing clients or conducting research on competitors and comparing pros and cons, we help. This process ultimately benefits us by revealing areas for improvement.

**Our high-touch customer service begins the moment a prospect contacts us.**

We use our capabilities in one market and enter a new market with the same expertise. We tailor the marketing and sales to the particulars of the new sector, but our beachhead is to sell what we have already built for an existing vertical. The process is as follows:

1. If we enter a new industry, we may not clearly understand how things work. Trying to develop a new business model causes context-switching problems and a loss of momentum and focus. Selling products and services we can already deliver but to a new vertical gets us in the door. 

2. Once we are in the door, we use that as a learning opportunity to understand the vertical’s needs and build our mental models for how the industry works. The best way to learn about an industry is directly from the customers. What are their needs? What are their pain points? What are the tools they are already using?

3. Once we understand the customer, we can build products specific to their needs. This includes developing partner relationships, distribution channels, and tuck-in acquisitions. By building after understanding, we reduce the waste in building new solutions.

4. The last step is to repeat this process to a new vertical.

This approach ensures that the focus is delivering value to the customer from the start as opposed to meandering around.