• Decentralization of Code

    The best way of creating our products within System6 is to decentralize it as much as possible to the point that each product can be a customer of each other. The only thing they share is the monolith and a database. This allows for the products to not have a dependency on each other and can be staffed to optimize for that resource.

    For example, as we build opsZero RI, opsZero Reseller, and opsZero OMYAC we need to not have those be dependent on other products that we are building. They should be autonomous even if we are duplicating code. This should also be the case with solutions. If we are targeting CMMC customers, those have independent requirements versus Startup customers so we need to make sure that the solution is targeted and being built for the CMMC customers.

    Every product and solution should independently maintain their own set of customers, or at the least perform like they have their own set of customers. They can loosely be tied to a Lead in our CRM but are otherwise independent. The benefit of this is also that as we develop me capabilities we can deprecate the old ones. We can isolate teams and test new features much faster.

  • Organizational Structure

    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.
  • Partner Based Growth

    We will release products and grow our business exclusively through partnerships. Our business is Cloud Infrastructure and our long term plan is to become a Cloud Marketplace. However, each vertical has domain specific knowledge we lack and do not have a large team limiting our reach.

    Partnerships

    When I look at our failures this year it has been largely around going into a new vertical alone. If we go at a vertical alone we have to figure out the market, the marketing, and sales. It creates the onus on us to deliver and sell and learn a new industry. Even if we move horizontally within an industry we will still need to context switch as we sell from startups to governments to healthcare. This prevents us from focusing on a single vertical making our growth feel haphazard and lacking focus. We need teams single threaded focused on each vertical.

    Traditionally, a company that wants to grow its business either hires people with expertise to build that business or buys a business that has those relationships. The problem with that is it becomes a capital expenditure where a failure means a total loss, partnerships allow us to make entering new verticals an operational expenditure. This reduces the cost of launching and testing something new and attacking it with people who are already knowledgeable.

    Our goal long term with opsZero is to build a bazaar style marketplace servicing the needs of multiple verticals cobuilt with partners. We will become a distribution focused company with the current services becoming another “partner” within the ecosystem. Our buckets are DevOps, DataOps, IT. All our products and services should live within these three buckets. And each service we release should have a partner who is responsible for servicing it.

    This changes the organizational structure of the company to be like a startup studio or incubator. While we should sell a cohesive whole to our customers, behind the scenes it can be our partners who service the end result for a particular vertical while we complement them with our value add.

    Solutions

    Our release methodology will change to the following:

    • Figure out the service we want to create for a vertical.
    • Find partners who could be good fits for coselling that product. Figure out ways we can partner with them.
    • Cobranded and create an OpsZero Marketing website and shared collateral and sell with partner. Focus on distribution and support the partner with data and sales resources.
    • Continuously work with partner to more effectively reach customers and service the work for the customers.

    The things we can do with a partner are three fold:

    • Comarketing such as content, webinar, videos or other.
    • Build new products that combines our strengths.
    • Emails or other joint collaboration.

    Products

    The question then becomes what do we do about products?

    The products we build for opsZero are single purpose tools that don’t generally have UX and are built fundamentally for a technical audience. Cloudflare, for example:

    • https://www.cloudflare.com/developer-platform/products/ is a non-technical website explaining the products that Cloudflare offers for a non-technical audience.
    • https://workers.cloudflare.com is talking about the same but built for a technical audience.

    We will do the same. The main opsZero.com website will be built as marketing for nontechnical audiences. We will build non-technical product pages if it fulfills a need otherwise we will generate self-serving product pages for technical audiences and link from the main website. This provides us with the ability to reach technical decision makers as well as non-technical ones.

    These technical pages will live within their own subdomain like the Cloudflare example above. For example: dodleads.opsZero.com

  • Long Term Evolution of opsZero

    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.

  • WordPress or System6

    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.

  • Demographic Changes

    We are all on the Titanic and are headed toward the iceberg. We are going to see profound economic changes by 2040 that will likely be the destruction of the capitalist economic model we have. The shift has already started and like will accelerate. That is the demographic shift.

    1. America will turn more conservative. Progressives don’t have kids. As conservatives have kids and those kids start reaching voting age they well tend towards conservative views. Likely this means that America will become a more religious place as well.
    2. Taxes will be higher. To pay for all the entitlements the tax rates will rise.
    3. Fewer things. The world is also aging meaning that we will just have fewer things as other places also run into worker shortages. Likely good for climate change.
    4. Real estate crash. Most places will have a real estate crash and the places that people want to live will have a boom.
    5. Equities crash. As people age and labor shortages arise a lot of the debt won’t be serviced. This will lead to lower returns and a general market contraction.
    6. Healthcare. Most money will be spent on healthcare.

  • Vertical Market Software

    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.

  • Appification

    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.

  • Moong Dal

    From Swasthi’s recipes. https://www.indianhealthyrecipes.com/moong-dal-recipe/#wprm-recipe-container-38286
    1/2 cup moong dal, rinsed
    1tbs ghee
    1/4 cup onion finely chopped
    1 tbsp ginger paste
    1-2 green chili
    4-5 curry leaves
    1/2 tsp cumin seeds
    1/2 cup tomato, finely chopped (1-2)
    1 tsp salt
    1/8 tsp tumeric
    1/4 tsp red chili powder
    1/2 tsp garam masala
    1 3/4 cup to 2 cup water
    1 tsp kasuri methi ( at end)

    Instant Pot directions
    in saute mode
    add ghee then onion, cumin seeds, green chilis, curry leaves. saute for a minute or two. add ginger paste. saute for 1 min. add tomato, tumeric, chili powder, garam masala, salt. saute for a couple minutes. turn off
    add moong dal and 1 3/4 cup water. deglaze pot. cook on high pressure mode for 10 minutes. let pressure drop naturally. add kasuri methi and then turn to saute mode to reduce amount of water until desired thickness.
    could add tempered spices if desired. could also add some spinach at final saute as well.

    Serve with pickle, rice or chapati, yogurt or raita.