Progressive Web-First Apps

You have a cool idea, and you don’t think “there is an app for that” yet. The path is clear, right? Build an iOS app, because the VC you are pitching has one in their pocket, and you want high ARPU customers.

When we were in the early gold rush years of mobile, this may have been the best path. There were a few things in your favor:

  • People were enjoying the novelty, and would go to the app store to checking out the cool apps of the day (akin to going to Yahoo! for cool new web sites)
  • There were a lot of popular services without polished mobile apps, so great developers had room to come in with amazing third party clients (e.g. Tweetie, which became the official Twitter client… a pretty common pattern)
  • The mobile Web wasn’t the greatest experience on early mobile
  • Graphs were up and to the right, so funding was highly available. I saw this first hand. For example, after launching the mobile apps at Walmart, if you projected forward, they would eat everything….. but the reality is that there are plateaus when you consider the time spent across various platforms, and there is room for the overall pie to still be growing fast!

Today, the opportunity to have impact is still very much there, and the world continues to keep jumping online, so the user base for your experience may still be growing, but the landscape has new challenges.

  • Many users aren’t going to the app store for discovery, are happy with the apps they have, and aren’t downloading many new ones.
  • The barrier of an app store may hurt your funnel, so the cost of acquisition for new customers may not be in your favor.
  • The reach of one platform is naturally much smaller than the meta reach of something like the Web.
  • We are moving past the “easy” years of only having to worry about 320×480, or desktop websites. Computing is going through much more unbundling, with many more form factors joining ecosystems. We need a way to build for a diverse-computing world.

What if there is another way? Progressive Web-First Apps.

Why would it ever make sense to start with a PWA experience for your new idea?

  • If you want to cast a net to reach as many people to prove out your product, the Web offers the reach. Once someone taps on a link you can get them into the experience to try without an install, and you can iterate quickly with simple A/B testing and the ability to make changes that don’t ever require an [UPDATE].
  • Chances are, you have some level of sharing. Now, no matter how a URL gets to someone, they can participate easily, and this can happen across desktop as well as mobile (and beyond). Other than some simple utilities, a huge number of my apps are getting and sending URLs out, and some are basically app browsers.
  • Speaking of desktop, while we have moved into a mobile world, many ideas can come to life in new ways on desktop and you have the ability to expand in that direction. Even today I have worked on products that have 80%+ desktop usage. Why limit yourself?

Progressive enhancement doesn’t even have to stop on the Web. If you prove things out and get to the point where you need to reach for native applications, you can! The beauty of doing things this way around though, is that you always have a funnel of new people who can access your service no matter what they are on, and for some customers they can go native if that is what they and you need.

But, starting a native app from scratch at that point sounds like a lot of work doesn’t it? You have options here too. Basecamp developers in a way that lets you bring your web investment along with you:

“We just launched a major revamp of the schedule in Basecamp 3. New calendar grid, new day drill-down, new navigation across months. It’s a big change, and we rolled it out simultaneously across five platforms: Web, Windows Desktop, OS X Desktop, iOS, and Android.

Three people did the work in less than six weeks.”

This strategy gives you control when you need to truly go native, and not waste time and effort when it isn’t needed. The features that are still in Web land continue to benefit from A/B testing and releases outside of the store. Not too shabby!

There are many other ways that you can play a similar game. For example, Ionic’s latest products are a great example of leaning into the Web. Stencil allows you to future proof yourself with Web Components all the way down, giving you a fast path on the Web, but you can take that to the native land with the backing of years of plugins.


But, let’s say you didn’t start this way, and you have ignored the potential broad Web users for your product, you are probably blind to the impact falling onto the floor.

Don’t worry, it’s not too late. In fact, there is no better example of turning this around than Pinterest.

We often hear about a new launch, but how did things really play out? Zack Argyle shares his one year retrospective.

The results stunned me:

“Now for the part you’ve all been waiting for: the numbers. Weekly active users on mobile web have increased 103 percent year-over-year overall, with a 156 percent increase in Brazil and 312 percent increase in India. On the engagement side, session length increased by 296 percent, the number of Pins seen increased by 401 percent and people were 295 percent more likely to save a Pin to a board.

Those are amazing in and of themselves, but the growth front is where things really shined. Logins increased by 370 percent and new signups increased by 843 percent year-over-year. Since we shipped the new experience, mobile web has become the top platform for new signups.

And for fun, in less than 6 months since fully shipping, we already have 800 thousand weekly users using our PWA like a native app (from their homescreen).”

Those numbers are not only impressive, they once again show the synergy with the native apps, bringing in users who may end up being happy in the web experience (including those who add to home screen) or may end up with a native app. Either way, happy customers!

ASIDE: Addy Osmani put together a detailed case study with the Pinterest team, to help you understand the work that went into this.

If you think about it, Pinterest is a great use case for this. It’s the type of experience that is on the board of content and commerce. You want to share this around, and for those who catch the URLs to join in, even if they aren’t members.

Just like Henrik, I hope we see much more of this trend. I want new ideas to spring up on the web, reaching users all over the world and giving you as much of a chance as possible to click with an audience. I am reminded of a friend, who built a learning platform that spiked in traffic. It turned out that the spike was because the Philippines ministry of education had decided to go all in on his software. He found his viability through the global reach of the Web.

And, I want existing companies to realize the low hanging fruit that is: making their website modern. On the one hand you can invision new features for your existing users, but on the other you can bring a new seamless funnel that will capture many new users from the Web.

So, crack open Lighthouse. Time for you to be the next Pinterest!

One Metric To Rule Them All!


People want focus! Move one metric! Up and to the right! Go non linear!

How do you focus an entire team or company? You just need to hold up One Metric To Rule Them All! I have heard this many times, and overheard a CEO talking about it just last week. I get it. Clarity is so much easier to rationalize and measure, so who wouldn’t rather have a black and white world?

The problem is that it is easy to go blind and start on a path that leads you to at best a local maxima, and most commonly to a rather bad spot, especially if you land on a vanity metric.

“What gets measured gets managed.” — Peter Drucker

While measuring is important, the key piece is making sure you are measuring the right things, and that you have a tension in your measurements. Take the time to have metrics that are in tension, or make sure that you put restrictions on the key metrics. Why?

Using the Levers

It is often easier than you think to force one metric. You often have multiple dials at your disposal, and you can point them at the metric at a detriment to the business. I learned this first hand in the world of eCommerce, where I was surprised to see how it was relatively easy to hit raw revenue numbers if you discounted profit. Your levers include pricing and buying traffic.

Vanity Metric Abuse

Input metrics can also be gamed. I recently saw someone who was measured on the number of people they were able to get to particular events. To juice the number, they were incented to get butts in seats with little regard for how qualified the people were. At some point they mentioned the fact that they even asked family to show up at times!

Quality vs. Quantity

To combat this, you have to balance quality vs. quantity. This is true in almost anything that you think of. Let’s take the number of people in prison. Surely we want less of them, right? The US has far too many people in the penal system, because it is ultimately unfair, as explained in this great book by Adam Benforado. We need to rethink policy and the incentive structures, and carefully balance the goal of having less people in prison, with the quality of people in there. In fact, the north star metric is a safe and fair society, and when you look at the problem through that lense, you broaden your view. For example, you remember that the system is meant to minimize offences, and isn’t there as a weapon of vengeance.

Ecosystem Views

This is why it is important to take an ecosystem view. I talked a little about this in my last post on the Web Ecosystem and how we view something as complex as the Web. The community needs to think of itself as regulators, looking to make changes that nudge things in the right direction. This broadens the view from “we make and improve our browser” (product) to “we do all we can to enable a healthy ecosystem, using all of the tools and investment options at our disposal”.

Short term vs. Long term

When you wear a regulator-type-hat, you are naturally thinking about the long term. This is important, as without this responsibility you are too tempted to get short term gains, which harm the long term. One of the root issues with climate change is the fact that manufacturing and the complex ecosystem didn’t have to factor the effects on the ecosystem into their market costs. This is what leads to the fact that a viable business can be made from flying water from Fiji around the world.

Add the fact that many workers have shorter stints in a role, or at a company, and you have to make sure that the incentive systems in place don’t force the short term. How does the performance review and promotion system think about work? Is your public company focused on the next quarters results for the market? Entropy is a strong force here to combat!

Segmentation and the long tail

It is important to spend time understanding the ecosystem you live in, and segmenting it correctly. Different ecosystems have different needs. The Web is naturally more long tail than other software ecosystems. The fact that everything is easily linked, mated with products such as Search that need to respond with an answer to many a niche query, force things in that direction. I personally love this about the Web, as it aligns the platform with allowing new incumbents and drives traffic to a greater variety of experiences.

Time to map it all out

So, take the time to really think through your ecosystem. First set north star output metrics for the ecosystem, then segment and learn what is happening, and finally have a strategy for what you want to change. From the strategy you can have the secondary metrics that can be leading indicators for the change that is coming (with ecosystems, often slower than you would like).

Make sure that you aren’t doing long term harm with your tactics. For example, with our love of “engagement”, it is easy to build viral systems that drive the wrong kind of engagement for our higher goals (not all engagement is equal). This is where your values come in (and often, strong founders) to make sure that you haven’t lost sight of the mission at hand.

This may be more work than driving ahead with that one metric to rule them all, but it’s worth it. And, there is even a “law” behind the danger, Goodhart’s Law, which Emily Freeman just brought top of mind:


How about building a model for the lifetime value of developers for your developer product? Ian Barber has a great analysis that he posted today!

Mission: Improve the Web Ecosystem for Developers

Once the dust settled on Google I/O 2018, it was time for me to find a new adventure. I wanted to share where I ended up because I am quite excited about it!

A few teams within Google have joined forces inside Chrome to focus on improving the Web ecosystem, focused on those who build experiences, and create on the Web. I am incredibly excited to be working side by side with Ben once again, and take on a new mission:

“We want to make high quality experiences easy to build as that will enable more meaningful engagement on the Web for users and developers alike.”

What is meaningful engagement?

We have to be careful what we measure. If we only cared about the amount of time that was spent on the Web, it would be tempting to do things that addict and actually cause harm….. just to get a number further up and to the right. We have all experienced sites and apps that seem to do just that, and it goes against our goals for humanity. Google wants to “organize the world’s information and make it universally accessible and useful.” Useful, not wasteful. We want to be a force for good.

Some of the core attributes that show the nuance of what we really want are:

  • We are not striving to get humans to spend more time on devices. This is a strong non-goal, and we care about digital wellbeing.
  • When someone spends time on a device, we would love their time on the Web to be with a great experience.
  • When someone wants to get a task done, we would love to streamline the effort which will result in less time spent on that activity, which is great!
  • We aren’t here to judge the type of activity. E.g. entertainment is meaningful for our users.
  • High performing experiences enable engagement because: Poor performing experiences result in abandonment, frustration, and platform switches; Each good experience results in myelination for reengagement
  • We want all users (reach) to be able to engage with the best possible experience (capabilities) for them.

There is a ton of nuance, and it is fun to spend time as a team thinking about what we want the world to look like, and drive for that reality.

How is the ecosystem doing?


While we have a fantastic, creative, community, it is clear that the Web that you experience daily does not map to the current capabilities of the Web. We are looking to work together to make changes that help close the gap, as when we see great modern experiencecs ship they see huge upside.

tl;dr Pinterest’s example here is the prototype turn around situation. Once a team focused on making their experience great it “became the top platform for new signups and in less than 6 months already have 800 thousand weekly users using our PWA like a native app from their homescreen”).

The future is already here — it’s just not very evenly distributed

One of the core issues at hand is shortening the time from “idea that makes the Web better” to “developers can use this idea and it is better for users”. There are a huge number of steps in between, and we need to shorten each of them. For example:

WEB PLATFORM LAYER

Web standards: Alex Russell recently posted two articles on the world of standards and lessons for becoming more effective. WICG and friends have both brought more web dev practitioners into the fold, and also streamlined the work. Getting consensus takes time, as it kinda should when adding something to the Web platform at this stage of its evolution, but that community is getting better at it over time.

Web compatibility: it is one thing to have a standard, it is another to have compatible implementations for developers. The Web Platform Tests effort has been huge here, and we see continued convergence across the browsers, which results in predictability for developers and users.

Web runtime: it is one thing to have implementations, it is another to have them be the implementations that are used. Chrome started the charge with rolling 6 week release cycles, and pushing continuous updates to users so they are running on the latest and greatest Web. Other browsers have also gotten better here. Being able to update here is critical. Time and time again we have seen situations where users are left on a device that isn’t getting updates and they are left in the past.

WEB APPLICATION LAYER

We see many pieces at play at the Web application layer:

Polyfills: One way to keep working towards the future is to be able to code to it’s interfaces even if all browsers in the wild aren’t there yet. This is where polyfills come in, as without them you either leave users out in the cold, or you are stuck back in time yourself. Getting your loading strategy working up front is important here. We still see, time and time again, web applications service polyfills to browsers that support the features natively. This eats up precious network and CPU, for no reason. It is important that a plan is in place for progressive enhancement that allows you to reach everyone, but deliver the best possible experience when capabilities match.

Frameworks: How do you keep up to date with the versions of frameworks? It can be tedious to keep upgrading, especially with large API changes. What is your strategy for keeping up to date here? For many, the “frameworks” are CMSes such as WordPress and Drupal. It was a huge win for the Web when WordPress supported updates inside of the admin panel. If you have a CMS that requires you to download zip files and do manual work to update…. you are probably spending more time in an unsecure past.

Libraries: We all know how those npm installs can blow up our dependency tree of libraries, so it is important to keep a watchful eye on these and once again have a plan for staying up to date. The nature of this work is tricky, and it is easy to be working with older versions of libraries based on transitive dependencies.

Your App Code: Oh right, you have to write the app itself! Hopefully you have A/B/release infrastructure in place that allows you to roll out the future to some users so you can see if that future is bright or not. With service workers, you have even more control of your application code, but that control means you need to make sure you have bulletproof infrastructure in place so you don’t lose users in the past as they get stuck in a historic cache.

CLOUD / OS LAYER

I remember the days where you had to keep your kernel up to date with the latest in security and performance patches. Fortunately, for many of us, those days are somewhat behind us, which is going to be important for future proofing.

The infrastructure that I would love to see in place, would allow for changes such as a new image format is introduced that is waaaaay smaller and faster:

  • Some browsers implement support and users get the capability in their hands
  • A WASM implementation is made available for browsers that don’t have native support
  • The browser and server are smart enough to negotiate and serve the new format in an optimal way.

Ditto for new networking solutions (as we rolled out QUIC et al). One of the fantastic things about AMP is how this world is available. A developer only needs to create AMP documents, and the rest is taken care of for you. And, with the AMP team constantly improving the runtime and the components, the same AMP page can keep getting better without you lifting a finger. With Web Packaging and the like, it would be great to do more of this outside of AMP.

One of the key notions of the progressive web, is that we are continuously improving. It is one thing to get the processes and platform chain of improvement working, and it is another to …

Make high quality experiences easy to build

You will notice “high quality” and “easy” are both in the sentence above.

Paul Calvano’s great piece on page weight

HIGH QUALITY

We harp on performance a lot, and the cost of JavaScript in particular, these days. We have taken a medium that was designed for streaming content and fast progressive loading and chopped it at the knees. Web development should offer you a pit of success but instead many stacks deliver a poor experience by default. If we could come together to fix one thing, it would be this.

It is one thing to run Lighthouse on an old legacy site and see a low score. You sigh, and know that you need to slog through a slew of work to bring it back to snuff. However, it is another thing to build a brand new app and run Lighthouse on it and …. also see a really poor score. The future we need starts you off high, and keeps nudging you to stay there. It has constraints and a mental model that allows you to scale your application. If you keep adding functionality, the first time to load can’t keep getting longer. At runtime, we can’t end up with a DOM with a million nodes, where the browser can’t keep up on layout, even if you are actually just making changes in one “view”.

Quality isn’t solely about performance though. We all want a Web that is also: capable, reliable, delightful, discoverable, and accessible.

I often think about this when I am on a website that offers the opposite. I had two such experiences in the last couple days:

Commerce experience: I was asked to purchase a gift card from a well known retailer. I first tried to grab one quick on a mobile device. The UI kept jumping around and the form controls actively stopped me from doing correct selections. I then jumped to the desktop version, and it was equally bad, giving me bizarre error messages that made no sense (and were different to those that surfaced on mobile). I then turned to the mobile application to make the purchase and pictured the data folks looking at these types of experiences and thinking “ah, so users of the app have better conversion!” No!

Push the app experience: I was looking to answer a question and ended up on a website that did everything possible to get me to download the app. There are plenty of reasons that I may want an app on my phone, but the “frustrate the user to do so” drives me insane. I buggered off to the next search result to get what I needed. I also picture data folks there looking at engagement and doing comparisons that don’t take into account that they are measuring different user segments. I have run into this time and time again, where the app users are those who waded through everything to get the app and are thus the loyal customers who put up with it. However, how about also opening the funnel to convert “not loyal yet” customers to the next level over time.

EASY

It’s too hard to build a great web experience. I made my own case here when you read through the infrastructure that you need to setup to build an engine that delivers up to date experiences. We have a paradox of choice, and it is easy to second guess yourself all day long (React or Vue? Web Components? Redux or MobX? Webpack or Parcel? etc etc etc).

Once you have made your choices, you have to make sure that they deliver a flow that is productive, and also delivers solid experiences (the PWA starter kit is an example of putting together the pieces that will keep you in the lane). The Web has plenty of footguns, so your experience can quickly become janky. To help us keep on the path we are improving the platform and also setting up Feature Policies that aim to guide. If you are able to policy up, the browser can optimize and users will benefit.

With all this being said, it is easy to miss out on the fact that the Web is still the best way to build experiences that reach users across form factors, and it has key principles that can’t be beat. Being able to fully control deployment on one end, and be able to make live changes in development on the other, is an amazing combination. If we can push through and have a nice native setup that allows for the best of these worlds without making developers live in config hell, we will be in a great place, and with recent changes we are able to get there.

We need a power assistant to help make this all happen. We have so many of the pieces already:

  • Lighthouse as a way to continuously understand how your development, staging, and production are looking in the lab
  • Chrome User Experience Report, Page Speed Insights, and friends to get you data from the field
  • Chrome DevTools is there to help you inspect, develop, and debug your applications
  • There are a few great editors, that are able to tie into the ecosystem
  • Community efforts to guide you down the path.

But we need more. We need to give developers better guidance and help them along. We need the tools to give more insights and give you greater help. You should be able to do more development and design work in DevTools. We need to help frameworks and ecosystems such as CMSes (e.g. WordPress PWA) and Commerce deliver great experiences to a huge part of the Web.


Guess what? We are hiring. If you would like to help us take everything to the next level and light the way to the pit of success, please let me know! We have positions across Product Management, Engineering, DevRel, and more. If you want to help the ecosystem and platform, we are all ears. Please join me on the new journey, one that will help the developers of today, and help us get to the future of a Web across new modes and form factors.