This is part of the AppSheet Manifesto series about the beliefs and principles that form the basis of the AppSheet platform. The manifesto has three major customer-centric assertions: a) about the technology, b) about the product, and c) about the business. This article is about the second assertion—a tiny startup team starts from scratch and rapidly builds a broad app platform for tens of thousands of customers. We have done this by adopting a somewhat surprising principle.
Our customers are our team. And here is what we mean by customers in the AppSheet dictionary.
Background: product development methodology
Before starting AppSheet, I spent more than 12 years at Microsoft in various engineering management roles. My co-founders also have significant experience at large software companies. As it turned out, much of what we learnt with that experience had to be un-learnt as we built AppSheet. Here's why. There are two broad models for product development.
One model says—we know the market, we know who the customers are, we know the requirements, we can build a better solution than the current state of the art, and we'll convince customers to try it and then buy it. This is the traditional model.
The other model says—we don't really the know the market, the customers or their requirements. We just have a vague idea. We cannot build a better solution when we do not know the problem accurately. All we can build is the raw outline of a solution. We have to put it in front of customers, learn from them, and iterate fast. This is generally called the "lean" model of product development.
Our philosophy took lean development one step further. We believed we could not really convince anyone to try what we built. Customers are smart, busy, and constantly fending off dozens of vendors hawking their products. Our potential customers have to actually want to try it themselves. We cannot find customers: they have to choose us!
"The wand chooses the wizard, Mr. Potter"
When a new person joins our company, I usually ask them a month or two into their tenure to try to personally acquire one customer. Convince one human being to use our product! It turns out to be difficult to do and particularly so in the early days of the product.
So why does a customer adopt an early and primitive product? It isn't because it solves a short-term problem. It is because it shows the promise and the potential to be molded into something that can really deliver value.
The wand chooses the wizard—the customer chooses to invest their time, energy, enthusiasm and commitment in the product. The customer who does this is an innovator in their environment, a risk-taker, an idealist. The customer is willing to pursue an idea that may have a low probability of success. The customer has "magic" and our product is only a vehicle for that magic to express itself.
So the crucial step in product development is to put ourselves in the neighborhood of these magic innovative customers and hope they will choose us. That's what we did by placing an add-on into the Google Sheets add-on store. The add-on simply said "Build mobile apps from your spreadsheet". And amazingly, we started to see a small but steady stream of customers trying our early product.
Now the next question is—what do we do with these customers when our early product is missing many important features, inefficient, and generally embarassing? The answer: listen to every word they say, and find ways to reach out to them to hear what they have to say. Because what they say sets the roadmap for the product.
Customers as our product managers
A product manager decides what features go into a product. By AppSheet definition, customers are our product managers. One of the first things we did was set up an online customer community. It started with three members, and just this week, it crossed 8,000 members! On a daily basis, we receive almost 100 messages and responses from customers.
Sometimes people asks for specific features that we don't have, for example, "Can I send an email when an order is captured via my app?" And we scramble to add a workflow rule feature. But far more often, it requires a back-and-forth to understand the real issue. Sometimes it takes more than one customer asking about something for us to realize how important it is. And conversely, if people don't ask for it, it probably isn't important.
This requires a commitment to read and to answer every customer message. In the early days, we would even proactively reach out to specific customers (e.g., "Hey, our logs show that your app is running really slowly. Can we do something about improving it?"). For a while, we ran a "Feature of the Week" poll. We asked our customers to vote for one of three features, and whichever was the winner by Friday, we'd work through the weekend to have it ready to deploy on Monday. An amazing and exciting time!
As the product has grown and the customer volume has grown, it has become a challenge to scale this level of customer engagement. We requested some of the leading community members to act as community moderators. This is actually one of the best attributes of our community—the community helps each other, the moderators are experts and when they raise issues directly with us, we know they carry the "wisdom of the crowd".
Customers as our engineers
Customers cannot design or architect our core product. That is our responsibility. All the same, there are many things we do that involve our customers in engineering activities. First and foremost, our software engineers directly handle product support and customer engagement. There is no buffer between customers and engineers. The more the engineers engage with the customers, the more they truly understand the product that should be built.
Our customers are also our product testers. We intentionally release new features when they are in an early beta state. With tens of thousands of customers with a huge variety of usage scenarios, we know we are not equipped to flush out all the use cases for a new feature. However, our customers are and they do.
Our customers write app samples that they share with others. And while we haven't done this yet, our roadmap includes the ability for our customers to write app modules that can be re-used and shared by other users.
Customers as our marketers
Marketing a product is a simple task to define—make potential customers aware that the product exists and can solve a problem for them. Most companies spend a lot of money on marketing. As a startup company, we simply didn't have the money to spend on marketing.
That helped us discover that our customers are actually our most effective marketers. Our initial set of customers found AppSheet via add-ons in the Google Docs ecosystem. We started to write content about AppSheet but found that nobody really wanted to read an article from yet another company talking about itself. On the other hand, we started writing stories about our customers and found these were way more compelling.
After a year in business, we started to observe an increase in traffic from people who came directly to AppSheet. We also found an increase in traffic from Google Search and the dominant search keyword was "AppSheet"! Which means all these new customers had heard about AppSheet from someone else. Almost always, from a happy existing customer.
It is one thing for a customer to try building an app with AppSheet. It is a completely different thing for a company to commit to moving its business process onto the app and paying for it. That requires someone to sell the idea to a decision maker and for that decision maker to commit.
We didn't have a sales team. So how did we end up with a few thousand paying accounts?
Very simply, it is because our app creators also became our sales team. Here is why we we say "customers are our sales reps" by AppSheet customer definition. Our app creators are innovators looking to change the world they work in. Once AppSheet allows them to convert their ideas into something practical, they "sell" and convince their organization to buy into their ideas.
Something else happened that we didn't anticipate—more than a hundred of our customers have become solution partners. They use AppSheet to build apps for other people. Some of them quit their fulltime jobs to pursue this new career. It is inspiring and amazing to see how this has evolved.
Our contract with our customers
- We will try to respond to every communication promptly. If you take the time to write, we should respond.
- The people who respond will have the knowledge and the power to make decisions. If we intend to support a feature, we will tell you so. If we don't, we'll explain why. If it falls in-between, we'll try to be clear on that too.
- We will take your collective guidance as we move the product forward.
- Yes, we're going to screw up occasionally—when we do, we will apologize.
- We're in this together.
As CEO, the most important part of my job is to listen to our customers, to respond honestly, and to take their collective guidance. Every customer has always had direct access to me just like every member of the AppSheet team in Seattle. My email address is email@example.com and I value every comment you send my way.
The AppSheet Manifesto Part 1: How AppSheet Was Founded
The AppSheet Manifesto Part 2: No-Code is "Know"-Code
In Founder's Notes-The AppSheet Manifesto part 4, we'll talk about design of the business aspects of AppSheet, how we think of partnerships, pricing, small business versus enterprise, and the role of customers in guiding this process.
Citizen Developers are Workplace Innovators. They build custom apps to improve and optimize work processes in their organizations, introducing innovative ways to "get work done." As citizen development becomes the new normal, it promotes innovation, agility, and flexibility throughout an organization. To learn more about AppSheet and citizen developers, check out the following page: