The World Doesn’t Want Your App
“We need to build an app. Do you know any good mobile developers?”
I paused, taking a sip of my coffee. “What makes you think you need an app?”
Waiting for his answer, I thought back to my days as a contract software developer. If you remember, the iPhone App Store opened in July of 2008. I was running a small web development consultancy at the time. Before 2008, every client was asking for an e-commerce website or a content management system. Within months of the App Store and the SDK being released, every client was requesting an app.
Now here I was, sitting in a hip San Francisco cafe in 2017, discussing strategy with a startup founder whom I advise. The more things change, the more they stay the same.
“We are targeting millennials, and they are all on mobile,” the founder said, his intonation lifting slightly at the end, as if asking a question. “We really don’t want to miss out on customers by trying to get them to go to a website to sign up.”
Indeed. But that didn’t really answer my question.
We all have been making apps and putting them on the App Store for almost 10 years now. But if you look at the data, only a small number of apps are actually being used.
Furthermore, these apps have pretty much all been made by the big technology players, like Google and Facebook. And yet, year after year, startups continue to build mobile apps that would be lucky to get a few thousand downloads.
“It’s great that you are focused on your customer acquisition strategy,” I said. “But if you put all your resources into a mobile app, your company is going to die before you really get started. Let me tell you what to do instead.”
The Great Decoupling
Gone are the days when a company’s value proposition could be more or less experienced through either a single web location or a single downloadable mobile app.
The most innovative companies today are providing a service, or set of services really, that touches the customer across a variety of different media and touch-points. There may be a mobile app for some types of interactions, possibly serving as the main touchpoint. There are usually other actions that require a browser. There may even be a chatbot, perhaps interacting over SMS, Slack, or Facebook messaging, but it will all be a seamless set of customer interactions that “follow you around” the Internet, rather than requiring you to go to a “place” online or on your phone.
This points to a phenomena that I call a “Great Decoupling”. I don’t know if that’s my phrase or I just heard it somewhere, but that’s how I am coming to think of this phenomenon that seems to extend across the boundaries of technology, business, and content.
The shift to platforms over single products as a business model, combined with the spread of open APIs, and the rise of chatbots and AI, make it less and less likely that a business model will exist only a single SaaS application.
Sure, software will continue to be consumed “as a service” well into the foreseeable future. But, the interfaces with which a customer interacts with that service will likely be spread across a variety of technology “products” and touch points.
Add to all the above some rather dramatic improvements in web and mobile development tooling in recent years, greatly reducing the cost and time required to stitch together impressive amounts of functionality with less and less custom coding.
[Enjoying this so far? You’ll love the Startup Patterns book].
Engineering: Fifteen Years To An Overnight Success
The transition from monolithic web apps to a services architecture has been underway for quite some time. As someone who has been writing code since 2000 (and continues to do so), it feels to me like we’re hitting a qualitative inflection point now in the way engineering teams approach services as a key dimension of application architecture.
Arguably, what we nerds used to call Service Oriented Architecture (SOA) is likely where this decoupling originated. Safely contained within the intellectual domain of software engineering, we’ve spent the better part of a decade-and-a-half learning as a community how to break big and bloated software systems apart into smaller fit-for-purpose components. But it’s all been behind the scenes until recently.
The separation of software into services is a critical enabler of what makes platforms and APIs — the parts of the system that non-engineers can actually see — possible at all, particularly at scales like that of Amazon, Netflix, and Facebook. What began as just good practice in engineering has led to the rise of flexible platforms on which wholly new businesses and applications can be developed.
That was the dream of SOA from the beginning, expressed within the narrow domain of a single enterprise, its focus mainly on cost-reduction. But by now, that pattern has bled over into the Internet writ large with profound implications for businesses everywhere.
Front-end Wizardry
Related to services is the improvement in front-end technologies. Witness the breathtaking flexibility of HTML5 and the myriad of powerful JavaScript frameworks like React and AngularJS. Because of services architecture, we can build interfaces (in the browser or the phone) without worrying at all about the business logic running on servers in the cloud.
And browsers, good gracious, are incredibly powerful and flexible. Your Chrome installation now comes with an entire IDE (“integrated development environment,” for you non-engineers) built right into it! You can sketch, build, test, pivot, tweak, and save entire web applications in the browser itself.
Continuous Delivery
Not least, we have the rapid maturity of a tool chain and infrastructure for deploying application changes from the developers’ machines to the customer’s machine at dizzying speed. Continuous Integration/Deployment/Delivery are industry terms we toss about to describe the automation of design, build, test, and deploy. These workflows allow an engineering team to experiment with dozens, possibly hundreds of variants of code per day. Remember when we used to do “releases” of software once a year, or even once a quarter? Yeah, that’s dead.
The sheer speed, power, and flexibility available to developers today through these tools and patterns translates directly in speed, power, and flexibility for business. They can now bring value to the customer across the vast range of platforms where they spend their time and attention.
Despite all of this still, many of us are still focused on the wrong things. We are still fetishizing the tools and technology. But what constitutes a really superior tool is that it becomes an extension of the body of the the tool-user, so much so, that she scarcely realizes it’s there.
Let’s certainly appreciate, but not fetishize, these advances. Your business is not an app. Any more than it is a building, or a stack of payroll receipts. Your business is a mechanism for the generation, distribution, and exchange of value. How that happens, if it happens at all, must now take place across a variety of platforms and systems.
You must design your business from the outside in, not the inside out, starting with the customer and their needs first. This can be done by moving on to the channels they inhabit and having a value proposition that will grab their attention, and then focusing on the delivery vehicles that will fulfill their needs. There will now be many delivery vehicles, and your job is to pay attention to all of them, without favoring any one of them.
“You need to focus on your core value proposition. What is your defensible competitive advantage? The things that solve a fundamental problem for the customer and at the same time do it in a way no one else can?”
He paused, clearly thinking hard about this. After a moment, he looked up.
“Well, the key is our data. We have data nobody else has. That’s our competitive advantage.”
Now we were getting somewhere.
Marketing: Fewer Castles, More Tents
The impacts of the Great Decoupling are not just technical. They reverberate throughout customer acquisition, engagement, and retention strategies as well.
Since content marketing exploded a few years ago, it is now taken for granted that makers of products should create novel content about their subject area as a way to build an audience. Customers will see them as an authority in the domain, the theory goes, and gradually adopt their products and services as trust is built.
Still true at a high level.
But the same forces that have pushed the decoupling of apps into multiple services and touch points have also been chewing away at acquisition channels and platforms, slowly transforming the rules of the game. We all rushed to set up a WordPress blog, drive content to our sites, and convert some portion of those readers into customers. In all likelihood, many of us still are.
But the success of content platforms (like Medium, for example) mean that carving out your website as a central location for your content seems like a losing battle. It is getting more expensive to acquire paid traffic to your site, because users are happily getting what they need on the big platforms. Dragging them off of Facebook or Twitter to visit your landing page — even with paid marketing campaigns — is getting harder and harder.
Instead, you’ll have to go to where your customers are already. Sigh. But this can actually be an advantage from a product development perspective.
Take Slack, as a final example. There are now a plethora of add-ons that you can install in minutes to improve your Slack experience. Many of these tools are introduced as a free bot, but have paid versions as an upgrade. Of course, the good makers of these tools would like you to kindly upgrade. They put work into making the bots awesome to entice you to do so. And in a few cases, I have.
Yet, a good number of them also are accessible via Facebook messaging, and have mobile and desktop tools to compliment their core service. It suddenly feels as though their service is conveniently available wherever I happen to be. I don’t need to download the app or remember the URL. The trusty bot is just there waiting patiently when I need it.
Don’t miss the critical point here: The developers of these services have isolated the value proposition for the customer (me, in this case) from the details of the interface where the customer consumes that service. This is only possible if you care more about value than about technology specifics. They are not caught up in the shiny distraction of the latest platform. Instead, they have built a flexible back-end that leverages a range of platforms as acquisition channels and engagement models.
This is the Great Decoupling at work. And it is game-changing.
“So it sounds like we need a web app, a mobile app, a chat bot, a Facebook page, and whatever else! How are we going to build all that?!”
Standing at the whiteboard (which I’ve magically wheeled into the cafe for the sake of this story), I looked across the room at the client. “The approach I would recommend is as follows.”
Build a version of your offering using only pre-existing technology. This means you deliver the value manually at first, no matter how unscalable it seems. Experiment with reaching customers across a range of popular platforms. Prove that you can deliver the value (in your case, a custom set of valuable data) through whatever channels they need.
Track your customers throughout the entire customer life-cycle. What platforms result in the highest conversion rates, the best user experience, the lowest cost? Prioritize the touch points in order of lowest overall cost of acquisition of customers and delivery of the service. After you have delivered value to a number of different customers on a number of platforms you can make an informed decision about building technology.
Gradually replace manual effort with technology components one at a time. Only when you are serving so many customers that you have to turn some away or put them on a waiting list, should you consider investing money in product development. But by then, you’ll have a good idea of which platform to build on first.
If you’re working on an app right now, please stop. Do you have customers? Have you validated that your value proposition resonates with them and that they will pay for a service you provide?
If you have, great! If you haven’t, we should talk.
