Hi All, Thank you to all of you who have submitted questions and participated in the twitter space yesterday. Here are some responses to the major questions we have received. I am sure we are not covering everything that has been asked but hopefully this answers most of the items that have been discussed.
-
Q. Why the focus on SNO costs? What other things are we considering to reduce costs beyond just SNO Payouts?
- When thinking about our costs it is important to understand that there are two main buckets of costs within the company, COGS (cost of goods sold) which are expenses directly related to the delivery of the product. In our case these are things like SNO payouts, the cost to run the metadata database, the salaries for Dev Ops people, and the gateway infrastructure. Then there is OPEX, which is other expenses such as R&D, Sales, Marketing, Finance, Travel etc. Right now our OPEX is much larger than COGS since most of the employee salaries fall into this category, including most of the engineering team since the majority of what they do is R&D not Dev Ops. This means that if you look at our token report SNO payouts look small relative to other expenses because we pay most people’s salaries with STORJ. But the goal for all start ups is to first get to gross margin profitable which means that revenues minus COGS is a positive number. Once you have that then you can increase volume and scale to overall profitability in time. Right now we are not gross margin profitable. And the biggest driver of that is SNO payouts which are 66% of our total COGS. In addition our costs and revenues are such that if we eliminated all other COGS we still wouldn’t be gross margin profitable. So we know that we must change SNO costs for the business to be viable
- That being said there are many other things also in flight to reduce the other costs buckets within COGS and many of these have been brought up by the community
- Reed Solomon code scheme changes
- This is a very high value target, but it has significant implications throughout the service (ex. impacts edge bandwidth usage, longtail cancellation, average piece size, compute required for client, repair bandwidth usage, overall performance, overall durability). Also,(other than the SNO costs based on expansion factor) it is otherwise not broken and there is a large amount of downstream work in terms of engineering effort, QA, documentation and tooling that needs to be changed if we change it. This means it is a large and risky effort, as it could impact data durability and we want to be very thoughtful and intentional about it. So while we are looking into it, it will be a slow careful process before we roll anything out.
- Free tier adjustments
- The free tier is currently growing but customers don’t seem to be using it to transition to paid customers as we had hoped. Because of this we do anticipate changing the structure of the free tier both to improve our costs and to better support our efforts to grow revenue
- Incentivizing gateway ST or native integration
- We already work with customers to utilize native integrations where appropriate. The dominant integration pattern for cloud storage is S3. We start with the gateway and then help customers get greater value from the larger integration effort for native. Native makes sense where throughput is important, where there is sufficient compute and bandwidth to be successful. We have Web2 (Univ. Edinburgh, GBLabs, Comet Backup, Rclone) and Web3 (Ankr, Pocket, Harmony) using native integrations. We can’t force it. It has to fit the use case.
- Reducing our infrastructure costs further
- Our other costs such as our metadata database as well as the Gateway infrastructure are things that we are constantly looking to improve. We know that we are sub-scale on many of these resources and so as we go per TB costs will improve, but there are also code changes and other implementation changes we can make to improve costs and these are all in flight.
- Reed Solomon code scheme changes
-
Q. Have we considered raising prices, or charging fees for value added features and services?
- We have explored raising prices for premium services, typically through partners like Ankr(chainsnap.io), GB Labs or private label partners, but we haven’t seen sufficient market pull for our current pricing to justify a general increase at this point. Growth is good and steady and we don’t want to add any friction at this point
- We are evaluating several options in packaging and pricing, including
- Reducing the free tier or transitioning from a free tier to a free trial
- Conversions from free tier have not yielded sufficient benefit to justify the expense
- We have also considered splitting some services to a paid tier only, or as a value added service, for example
- Linkshare service
- CustomTLS for Linkshare
- Edge Services
- Enterprise support
- Reducing the free tier or transitioning from a free tier to a free trial
-
Q. What is the time frame for making changes to SNO payouts?
- We’ve tried to be clear that we want to avoid a shock to the system or a dramatic drop in node payouts. From a rough timeline perspective, our goal is to get to unit profitability by the end of the year.
- What SNOs can expect is the following
- As customer usage increases, we will reduce test data from the network at a rate that matches the rate of growth
- This started last year and will continue until the test data no longer represents a subsidy, but is restricted to what is needed to validate product capabilities and for QA
- We will reduce the payout amount slowly throughout the course of this year
- While we’re reducing SNO costs, we’re also working equally hard on the other COGS to ensure that we hit our end of year objective
- As we make changes, we want this dialog to stay open.
- We may find more opportunities where we can offer higher price points and better returns for SNOs
- We’ll continue to find a balance that works for both SNOs and Storj
- As customer usage increases, we will reduce test data from the network at a rate that matches the rate of growth
-
Q. We have an oversupply of storage and not enough customer data. What are STORJ’s plans to find new customers? Who are these customers? Who are these customers? What do they currently use? What advantages can STORJ offer them? What does STORJ do to convince them to switch?
- It might help to share the general approach we take to sales and marketing, which is not dissimilar to what you might find in any disruptive startup.
- We have a marketing team that is very focused on the target customer and target use cases. The largest areas for rapid growth are in higher egress use cases for existing customers of hyperscale providers. The marketing team drives leads to the sales team and provides assets and touchpoints to help nurture leads into sales opportunities.
- We have increased the size of the sales team by 4x over the last year. This team is responsible for leveraging the leads generated by marketing as well as identifying prospective customers and converting them to paying customers.
- We’ve started with early adopters and have many referenceable customers. They are growing in number and size. Early adopters tend to be small and innovative disruptors. They help you move up market to SMB (Small and Medium Businesses) and those SMB references allow you to break into the enterprise market.
- Other things that end to help include third party validations from tech media, analysts and external reports published by partners and customers.
- Who have an exceptionally high customer NPS. Many of our customers and partners are now participating in our webinars and joint presentations a t conferences.
- Ex. Livepeer and Storj workshop at ETH Denver
- Iconik and Storj presentation at IBC
- In addition we are also working to make the creation and operation of community satellites more accessible and hope that over time other individuals or organizations beyond Storj Labs will be able to drive demand to the network
- It might help to share the general approach we take to sales and marketing, which is not dissimilar to what you might find in any disruptive startup.
-
Q. Since changes have huge economic impact on SNO’s will Storj also review or remove restrictions currently in place including IP /24 rule & the Vetting period
- RESPONSE:
- There are a few points to address in this question
- Vetting period - We’re already horizontally scaling audit workers to address the vetting period
- IP /24 rule
- This restriction is in place to help preserve the distributed footprint of the data stored on the network. It is really about how data centers co-exist in the network with individual contributors. Data centers already participate but adding a lot of capacity isn’t advantageous as all nodes tend to fill at similar rates. We are looking at how data centers can participate in the network without introducing a category of node that can disproportionately outcompete individual operators.
- There are a few points to address in this question
- RESPONSE:
-
Q. Where are with compliance / certifications
- We are working on our SOC2 certification and are more mature in terms of the less complex frameworks such as HIPAA and GDPR
Reference: The European Data Protection Board (EDPB) recently issued a recommendation that states that encryption is actually a sufficient protection for data that is protected by GDPR