Browsers, Innovators Dilemma, and Project Tofino
update 08/04: I should have been clearer that Project Tofino is wholly focused on UX explorations and not the technology platform. We are working with the Platform team on technology platform futures too, and we’re excited about the Gecko and Servo-based futures being discussed! Also, don’t forget to check out the companion post from Philipp: Designing a Browser that isn’t a Browser. Finally, go straight to the GitHub repo for actual project details. Thx!
Last time I posted, I talked about Content Blockers. We ended up making one, and the world didn’t end. Yay! Blogging helped me sort it out in my own head, and that helped identify a path forward at work. So I’m going to do some more blogging, because I’m kicking off a new project which triggered a bunch of soul searching about products, innovator’s dilemma in particular, and what taking risk feels like. Maybe talking about it will help me sort some of this out. So, here we go.
Let’s jump right in and say yes, the rumors are true, we’re working on browser prototypes that look and feel almost nothing like the current Firefox. The premise for these experiments couldn’t be simpler: what we need a browser to do for us —both on PCs and mobile devices — has changed a lot since Firefox 1.0, and we’re long overdue for some fresh approaches. It’s worth noting that we have a ton of work underway on our flagship product, Firefox, that’s all about evolving the browser experience. Not to mention the huge bet we’re making this year that we can get the biggest changes to Gecko we’ve ever attempted (e10s) to land so that Firefox is on a healthy, competitive footing for years to come. But it’s not enough, when someone has a totally different idea they want to explore.
We’ll blog on the Project Tofino Medium channel about the project itself, but what this and subsequent posts are mostly about is thoughts on what the business of doing “innovation” at an organization that has a lot to lose feels like. It feels hard. Up to this point in my 20 year career (20 years? right?!), I’ve never experienced anything quite so “textbook innovator’s dilemma” as my last year at Mozilla. Let me explain. What’s probably not surprising is that the team that builds our browser has a lot of great insights and ideas about how people actually use browsers and the kinds of problems people have that aren’t currently solved by anybody’s browser product. Also likely not surprising is that said team would be stoked to build an entirely different kind of browser focused on solving those problems. Focus. Freedom. Yes! What’s not intuitive to anybody that hasn’t experienced the backside of a very successful product run is that creating something new and different is incredibly difficult. Every little decision can bring crushing stop energy. At an academic level, this is fascinating. Everyone’s read about this in books. When you live it, it’s very personal. The reason new things at old shops is difficult, mostly, I think, isn’t because people are bad, or stupid, or actively sabotage new projects or any nonsense like that. It’s largely because doing anything that might conceivably impact the current product creates unavoidable tension. Nobody likes tension, so you replace it with that self-created stop energy. Innovator’s dilemma is a real thing.
For example, the prototype we’re feeling good about right now is built with Electron and React, not Gecko and XUL (our go-to technologies for building browsers). For a small team starting out pursuing a new product concept it’s a great choice — Electron is a wonderful tool for us to do prototyping with — but a simple decision like picking the right tool for the job becomes an epic FUD generator when it could be perceived as threatening to the existing product. Immediately, you worry. Does it signal we don’t believe in Gecko? What will the platform team think? Will they believe us that the project has nothing to do with technology selection, that’s what browser.html is for? What if web developers think we’re abandoning Firefox, and Gecko? We’ll lose on web compat, and nothing will work in Firefox! Consumers will abandon Firefox in droves! We’ll lose our influence at the W3C! OMG the web is dead! I’m not making fun of that. I’ve had all of those thoughts. And spent countless hours thinking about how to deal with the others that will inevitably have them too. Before you know it everybody involved is spending countless hours worrying about about outcomes that we aren’t in control of anyway. Not having an awesome Firefox will kill Firefox. End of story.
There’s a great deal we don’t know about creativity and innovation. But the research does suggest some patterns are more common than others. You can expect tension. No amount of “messaging” can work your way out of that. The tension will be there, you have to accept it, or you never move. There will be risk. Again, accept it or you never move. You should trust in small, cohesive teams. You should support them, and encourage risk taking. That’s often referred to as “creating space”. My personal experience has been that all these things are true, but I’ve also seen that if you make the innovation process “easy” whatever is being built ends up sucking. Especially at the front end of the process. Maybe it’s because ideas are free to create and valueless on their own. I don’t know.
In that spirit, today I’m placing a bet on a small, cohesive team that for the last 6 weeks spent hours I know for a fact they didn’t have, hacking on an idea they simply refused to let die. God knows the last month of stop energy should have killed it. Years of fear of hurting Firefox, by rights, should have never even let the idea germinate. But somehow they held on and fought for it.
We’re setting up the project a little differently too. The team is not open for internal transfer. The team no longer has access to their own calendars. They’re being unsubscribed from all email lists. They’re not going to attend even a single Mozilla meeting. We’re kicking off in person, everyone in a room, in Tofino on Vancouver Island where the idea for this UX direction originated last summer, and from there we’re going to co-locate the core team in Vancouver for 3 months. That’s how much time I’m giving the team to prove there’s something here that we could turn into a product. If not, we kill it. We’re not going to expect help from anyone at Mozilla and we’re not going to distract the other 95% of our team that’s doing hero work on Firefox.
Origin stories have always fascinated me, and when I look back, a great deal of Firefox’s origin story is not well known. Whether a successful product or feature set comes from this project or not, I can’t say, but I’ll at least document the story of how we’re building new browser experiences inside one of the world’s most experienced browser teams. I’m looking forward to being their story teller!
