STOIC turned one today! We were born Sutoiku just one year ago.
It’s quite amazing what we managed to build in a year…
I can’t wait to see what STOIC will look like after another year…
Thank you all for letting us have this amazing ride! I’ve not had that much fun in a long time…
For the past two months, we’ve been maniacally focused on one metric: the week-over-week growth of our Kickstarter pre-registrations (Cf. How focus on growth changed our business). Moving forward, we will expand our focus to cover a few more metrics:
Adoption
Once our software becomes available, we will replace our primary registration metric with a composite adoption metric defined as the sum of the number of paying customer c and total number of users u, divided by two.
α = (c + u) / 2
We constructed this composite metric in order to take into account both the number of customers and the total number of users at a time when each customer will have a small number of users, usually just one (the original app maker who subscribed to STOIC). Eventually, we will track c and u individually.
Most importantly, we will track the weekly growth of this adoption level (Cf. Startup = Growth).
Average Revenue Per Unit
This metric tracks the average revenue per customer, on a monthly basis.
Customer Acquisition Cost
This metric tracks the cost of acquiring new customers from a sales and marketing standpoint. A simple way of measuring it is to divide the total amount of money spent on lead generation and deal closing activities over a long-enough period of time (ideally a year), by the number of new customers signed over the same period (possibly with a small time offset).
Customer Lifetime Value
In order to measure the return on investment from our marketing campaigns, we will track the value of a customer over its lifetime. The absolute value of this metric is not important. What matters is how it evolves over time, and how it contributes to much more critical metrics, such as the Time to Return on Marketing Investment.
Time to Return on Investment
This metric tracks the time it takes to get a positive return on marketing investments. If the customer acquisition costs are $X and the Average Revenue Per Unit is $Y/month, the average Time to Return on Investment equals X divided by Y. Obviously, a business for which the Customer Lifetime (Customer Lifetime Value divided by Average Revenue Per Unit) is lower than the Time to Return on Investment is not profitable and is doomed to fail eventually.
Churn
This metric measures the ratio of customers that are not renewing their subscriptions.
Revenue per Employee
While we will do everything we can to maximize our total revenue, the revenue per employee ratio will be even more important to us. And once we become profitable, we will replace this metric by a profits per employee ratio, which is a pretty good measure of the value created by every member of our team. Until we’re profitable, we will closely monitor our funding runway.
Community Engagement
In order for our customer development process to work effectively, we need as much participation from users as possible, especially at the validation stage. For this purpose, we will track the number of individual answers we’re getting from surveys. This metric will be directly influenced by the number of surveys and polls we run, but actual participation is what matters.
Crowdfunding Activity
According to our customer development process, the development of most major product features should be funded through dedicated Kickstarter campaigns. In such a context, we will track both the number of backers and the number of individual pledges we’re getting for our Kickstarter projects. These metrics will be directly influenced by the number of Kickstarter campaigns we organize, but actual participation (backers and pledges) is what matters.
Crowdfunding Ratio
This metric tracks the ratio of crowdfunding for the financing of all R&D activities.
Virality
This metric tracks the ratio of new customers who came through referrals.
Channel Effectiveness
This metric tracks the ratio of new customers who came through partners.
Development Velocity
The velocity of our product development process as defined by Pivotal Tracker will be tracked on a weekly basis. While it can be used for forecasting purposes, we will use it mostly as a way to learn from the past and improve our project management skills.
Release Completion
We will monitor the completion level for our next product release, also using Pivotal Tracker.
Test Coverage
The number of lines of code covered by automated tests divided by the total number of lines of code is one of the primary metrics we will use to estimate the theoretical quality of our code. Over time, we might add similar metrics to cover the documentation coverage of our code.
Product Fit
This metric tracks the aggregated utilization rate of individual product features across the entire user base. It is measured by instrumenting the product with as many usage monitoring and metering sensors as possible. Such sensors capture anonymized and obfuscated data points that are both qualitative and quantitative. Its evolution over time indicates whether the product is getting better at addressing real user needs, or is subject to uncontrolled feature creep.
User Self-Reliance
In order to asses the quality of our product, documentation, and community-lead support process, we will measure the average number of support tickets created by users. Obviously, we will want this ratio to be as low as possible, and to decrease over time.
Moving forward, more and more metrics will be added, many as the aggregation of sub-metrics. While we can’t promise that we will share all of them publicly, we will do our best to share the most meaningful of them, including our weekly growth rate. Stay tuned for cool dashboards!
We’re looking for T-shaped people who are comfortable with AngularJS or Node.js, or both. Familiarity with our foundations is a plus.
Applicants must be willing to relocate to Flatland. Offices in Palo Alto, Shanghai, Singapore, and Caen. Telecommuting considered for exceptional applicants.
3% 401(k) contribution
100% health coverage
PPO included
Vision included
Dental included
Orthodontics included
$20 daily lunch allowance
$4,000 BYOD budget (eat some fruits)
We do not discriminate against robots or ninjas.
Before you send us your resume, please contribute to one of our open source projects, or send us a sample UI built with AngularJS.
STOIC turns Google Spreadsheets into apps, with a cloud database and a mobile user interface.
Since we started STOIC almost six months ago, we’ve been approached by a few venture capital firms who expressed interest in investing in the company. Because we’ve already raised money from a strategic investor, we kept in touch, but did not engage in any serious discussions. More recently though, one potential investor challenged us to think in a non-linear fashion, and to suggest ideas that could help accelerate the growth of the company. We rose to the challenge and came up with something truly unconventional: STOIC Ventures, a new kind of incubator, or what we’d rather call a venture accelerator.
At this stage, it’s nothing more than another crazy idea, and it’s quite likely to remain just that. Nevertheless, putting it on paper helped us refine our thinking in a few areas, especially with respect to the crowdsourcing of software development, which we’re committed to implementing with Poetry.io. So, while we still need to convince ourselves that something like STOIC Ventures is actually doable and is not just a massive distraction, we would love to get your feedback on the idea, especially with respect to the different services that are suggested. Please cast your votes using our cute little rating stars, or send a pre-application for funding if you fit the profile.
Yesterday night, I attended a dinner organized by David Allen. There, a dozen entrepreneurs discussed about what productivity software might look like in 2020. I can’t disclose the full list of participants, but I can say that David managed to put together an amazing brain trust, and the discussions were highly stimulating. After the dinner, Evan Williams suggested that I take a look at Holacracy in order to formalize a bit more the rules that we will need to live in Flatland among T-shaped people. I guess I have my reading list for the week-end. Thanks Evan!
Be it for Flatland or T-shaped people, Valve Corporation is a major role model for us. And after this excellent New York Times article, I would expect that it will be for many more companies. But if you’re considering such a model for your company, keep in mind these recommendations:
Over the past few weeks, we’ve been working with our lawyers to define our long-term strategy regarding intellectual property. It’s a fascinating topic, but a rather complex one, especially when you consider the inter-relationships between the common types of intellectual property rights, including copyrights, trademarks, licenses, patents, design patents, and trade secrets. Let me cover them one by one, while outlining some of the most critical inter-relationships among them. And keep in mind that I am not a lawyer (unlike my brother), and that we’re working with three different law firms to put all this together…
Copyrights
This is by far the easiest part. By default, everything we produce is automatically copyrighted. Adding the © symbol on every piece of content that we create certainly does not hurt, and we’re likely to register our work once or twice a year just to be safe. Beyond that, we will start licensing some parts of our work using Creative Common Licenses, but we need to become a bit more familiar with them first.
Trademarks
Now that we’ve acquired the stoic.com domain name, we’re in the process of shifting our brand from Sutoiku to STOIC. First, we’ve started the registration process for the STOIC trademark. Second, we’ve registered a few additional domain names (stoic.cc, stoic.io), and we might register a few more down the road. Third, we will eventually rename our company from Sutoiku, Inc. to STOIC, Inc. or STOIC Corp. We might also apply for a trademark in relation to the simplify™ campaign. Finally, we will try to rationalize our handles on various social networks such as Facebook (stoic.io) or Twitter (@wearestoic), but things there are a lot less straightforward unfortunately.
Licenses
By default, our software will be licensed through a traditional end-user license agreement (EULA) and our online services offered through conventional terms of service. But we’ve also started a few open source projects. These are licensed under the MIT License, because it’s one of the simplest and most liberal. It’s also the most popular license within the JavaScript community (Cf. Community ethos). And as you would expect, we’re using quite a few pieces of open source software to develop our own product (Cf. Foundations), but only software licensed under liberal (non-viral) licenses such as Apache, BSD, or MIT. Granted, we could use the GPL License and a dual-licensing strategy made possible by the inter-relations that exist between copyrights on one hand and licenses on the other (ask Maureen at Paradigm Counsel for the English translation), but we’d rather keep things simple…
Patents
For a software company, patents are always a rather tricky subject, and we’re not exempt from it. On that front, we’re likely to apply for a few patents covering very specific aspects of our work, but none that would even remotely relate to our open source projects. What’s a bit challenging for us is that many of the ideas that we’re implementing at STOIC are the direct result of interactions with our community, especially on this blog. As a result, we need to be very careful to not talk or write about anything that we might want to patent at some point. Since we don’t have a lot of experience in this area, we will apply for a couple of utility patents for the ideas that we feel are truly novel, and use provisional applications for everything else. This should save us quite a bit of time and money.
Design Patents
Design patents are a type of industrial design right. We might apply for some in order to protect our logo, user interface, and icons, but they have a much lower priority on our list, mostly because our designs are very likely to change quite often, especially in the early stages of development.
Trade Secrets
Like any company, we have trade secrets that need to be protected, and we do that mostly through the use of solid employment contracts and secure communication tools. For the latter, we mostly rely on Google Apps, with the acknowledgement that Google has considerably better and larger resources than us that can be deployed on the IT security front. That being said, trade secrets are not very important for us, especially considering our open kitchen culture. It’s not something that our lawyers are super excited about, but they’re being paid to worry about this kind of things. We’re not. Or to be more precise, we’re being paid to break as many rules as possible, so that we can out-innovate and out-execute our competition. Game on!
We’re now on Twitter with the @wearestoic handle. This is where we will push all our news moving forward, so make sure to follow us if you want to stay up to date with our little company. Now, I just wish we could get the much simpler @stoic handle… Oh well…
Another concept we borrowed from Valve and their handbook for new employees is Flatland. “It’s our shorthand way of saying that we don’t have any management, and nobody ‘reports to’ anybody else. […] This company is yours to steer—toward opportunities and away from risks. You have the power to green-light projects. You have the power to ship products.”
“A flat structure removes every organizational barrier between your work and the customer enjoying that work. Every company will tell you that ‘the customer is boss,’ but here that statement has weight. There’s no red tape stopping you from figuring out for yourself what our customers want, and then giving it to them.”
We could not have said it better.
Following our CTO’s intuition, we’re drawing a lot of inspiration from the way Valve Corporation is running its business, as best described in its fabulously iconic handbook for new employees. One of the ideas that we particularly like is the concept of “T-shaped” people, “who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow discipline—the vertical leg of the T).” To be clear, anyone applying for a job at STOIC should pretty much look like a T.
For some reason, we have yet to introduce our Chief Technology Officer. He’s been busy working on our server and a few other things, but his days in the shadows are now being numbered. As I’m writing these lines, he is putting the final touches to the website he built for promoting one of the few open source projects that we’re planning to release this year. So stay tuned for some announcements to be made soon…
After four months in business, we finally managed to put together a formal deck for our monthly Board of Directors meeting (the next one is scheduled for Monday). While we could justify this delay by the fact that we’ve been pretty busy, I understood today the real reason for our procrastination: we did not know what would make a truly good deck, and did not want to waste time building one that nobody would really care about.
Most decks that I have seen (or built) focus on the past by listing the company’s achievements, and on the future by outlining the company’s roadmap. Unfortunately, the former does not really matter anymore, and the latter is all too often nothing more than wishful thinking. What’s missing in this picture? The present, which is where the action is, and to which the attention of anyone attending the meeting should really be devoted to.
How should the CEO talk about the present? By listing the questions to which he or she does not have any answers. Discussions about these questions should take most of the time allocated to a Board meeting. Unfortunately, most members of the Boards of VC-funded companies tend to be investors, and it’s all too easy for the CEO to consider job preservation as number one job. In such an environment, too many questions can be perceived as a weakness on the part of the CEO. As a result, very little time is devoted to discussions, and the meeting is a massive waste of time for most parties involved. I have attended over 200 Board meetings so far, and I can’t remember more than a handful during which really constructive discussions took place.
Fortunately for us, our Board of Directors isn’t made of investors. It’s made of two founders and two independent Board members that we handpicked for their experience, expertise, and wisdom, plus an observer whose personal experience is greater than the one of all four founders put together. And for once in a really long time, as CEO of Stoic, I don’t have to worry about job security, so I can open up freely, exposing all my doubts, interrogations, and questions.
So, what does our deck look like?
Ten slides, with two third facts and one third questions, on every slide.
It’s Friday, but I can’t wait for Monday to get some answers to my questions.
Since we started our company, we’ve had to spend a fair amount of time explaining the meaning of our name (Sutoiku), how to spell it, and how to pronounce it. The name is a deliberate misspelling of Sutoikku (ストイック), which means “stoic” in Japanese. I personally love it, but for a company name, it’s less than ideal.
For this reason, we decided to switch to “Stoic” for our company name, and stoic.io for our upcoming corporate website. We will keep using “Sutoiku” as name for this blog, and keep its hosting at sutoiku.com. The official name for the company will remain “Sutoiku, Inc.”, until we change it to something like Stoic Software, Inc. (Stoic, Inc. is already in use).
So, from now on, we are Stoic.
