Firefox Differentiation

2 views
Skip to first unread message

Sherman Dickman

unread,
Jun 24, 2006, 2:00:34 PM6/24/06
to dev-planning
All,

In a recent post, I outlined some of the activities and deliverables
that a product manager (PM) helps to coordinate. Over the next few
posts, I'll dig into some of these a bit deeper and will eventually
tie them together in some fashion.

I was first introduced to the concept of "Vectors of Differentiation"
in an excellent book by Michael E. McGrath titled "Product Strategy
for High Technology Companies." It's one of the best books I've read
on the subject, and since I've had good success with his concepts in
the past, I thought this would be an interesting one to start with.

A product is differentiated when its user-valued features are
considered *superior* to what is available in alternative products.
The greater the differentiation, the more attractive a product
becomes relative to the competition. A vector provides a path for
continuous differentiation in a specific direction over time. Thus, a
vector of differentiation essentially says, "this is the direction
that we’re taking our products to provide superior user value, and we
are going to stay ahead of other offerings by doing it better and
better."

So in what ways does Firefox provide the end user with a superior
browsing experience over IE 6? Some things that come to mind include:

* User Experience - tabbed browsing, integrated search, RSS
bookmarks, etc.
* Customizable browser add-ons
* Cross platform support
* Better track record on security
* Better compatibility for Web standards

Firefox's differentiated value is clear to millions of users,
particularly for those who frequently browse the Web. Now, Internet
Explorer 7 could potentially close the gap on many of these
differentiators through:

* A new user experience with tabbed browsing, integrated search,
RSS support, etc.
* Add-ons (see: http://www.ieaddons.com/)
* A renewed focus on security and standards compatibility

(NOTE: This is just a high-level example to demonstrate the concept
of a VOD, and should NOT be considered a full competitive analysis.)

Our challenge is to provide a level of differentiated value that is
so clearly superior to competitive offerings that users will be
compelled to choose our product. This can be approached in one of two
ways:

1. Continue along our same vectors of differentiation (user
experience, add-ons, etc.), but innovate faster than the competition.
2. Redifferentiate along new vectors that are of high value to
users.

The first approach is somewhat obvious, but what does
redifferentiation look like?

Rather than trying to compete with the wintel platform in a market
that was rapidly heading towards commodity status, Apple sought to
redifferentiate itself by focusing on industrial design (the iMac)
and ease of use, particularly for connecting to the Internet
(remember the ad campaign "there is no step 3?"). In doing so, they
played to their strengths and steered clear of existing
differentiators such as price, application availability (vs. windows
offerings), perceived system performance, etc. Since then, Apple has
continued to differentiate over time on industrial design and ease of
use, but with an additional focus on providing the best user
experience for the creation and consumption of digital media (iPod,
iTunes Music Store, iLife).

I would like to get your ideas on differentiation to help frame
future discussions on product strategy. I'm looking for your opinions
on the following questions:

* Should we continue to innovate along our existing
differentiation vectors? What do you think those are, and what are
the best ways to achieve them?
* Should we try to redifferentiate into new vectors, and if so,
which ones are best for us to target? Which ones play to our
strengths and which should we abandon?

- Sherman

Bernd

unread,
Jun 25, 2006, 12:42:21 PM6/25/06
to dev-pl...@lists.mozilla.org
Sherman Dickman wrote:
> * Should we continue to innovate along our existing differentiation
> vectors?
NO, we should not. ;-)

This not a question, but pure marketing speech where the communication
partners have anyway to agree. Its so obvious that the whole browser
business is about innovation.


>What do you think those are, and what are the best ways to
> achieve them?
> * Should we try to redifferentiate into new vectors, and if so,
> which ones are best for us to target? Which ones play to our strengths
> and which should we abandon?

I am serious in doubt, are you really talking about FF3?? Do you believe
that from a marketing standpoint http://wiki.mozilla.org/Firefox3/Goals
omits important goals that should replace the existing ones?
The schedule is tight even for FF3
(http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan) considering
that some features already dropped from FF2 and moved into FF3.

Bernd

Frank Hecker

unread,
Jun 26, 2006, 4:43:11 PM6/26/06
to
Sherman Dickman wrote:
> * Should we continue to innovate along our existing differentiation
> vectors? What do you think those are, and what are the best ways to
> achieve them?
> * Should we try to redifferentiate into new vectors, and if so,
> which ones are best for us to target? Which ones play to our strengths
> and which should we abandon?

(Terminology note: Since my perspective on innovation comes from Clayton
Christensen, what you refer to as "existing differentiation vectors" and
"new vectors" I think of as "sustaining innovations" and "disruptive
innovations" respectively.)

I'll make two general comments:

First, in terms of existing differentiation vectors (sustaining
innovations) I would look not just to end user features but also to
features of interest to developers, both extension developers and
developers of web-based applications, given their importance to
promoting use of Firefox as a base for their own innovations. For
example, I was catching up on my blog reading and noted this post on the
Zimbra blog:

http://www.zimbra.com/blog/archives/2006/05/openajax_update.html

that contains some Firefox feature requests.

I'm sure other people have made other requests along the same line.

Second, with regard to new differentiation vectors (disruptive
innovations), I think the best guide is Christensen's recommendation to
look at the "jobs" people "hire" products to do, and see where Firefox
(and Mozilla technology) in general could enable people to do things
they want to do, but find too expensive and/or onerous to do today. Some
of this might be enabled directly by Firefox, and some indirectly
enabled by using Firefox as a platform for web apps or Mozilla
technology generally as a base for other web-enabled applications. (For
example, as the Songbird folks are trying to use Mozilla code to build a
product to support the kinds of things that people interested in online
music might want to do.)

Frank

--
Frank Hecker
hec...@mozillafoundation.org

Frank Hecker

unread,
Jun 26, 2006, 4:49:11 PM6/26/06
to
Bernd wrote:
> I am serious in doubt, are you really talking about FF3?? Do you believe
> that from a marketing standpoint http://wiki.mozilla.org/Firefox3/Goals
> omits important goals that should replace the existing ones?
> The schedule is tight even for FF3
> (http://wiki.mozilla.org/Global:1.9_Trunk_1.8_Branch_Plan) considering
> that some features already dropped from FF2 and moved into FF3.

I don't want to speak for Sherman, but I don't think he was necessarily
talking about doing all this for Firefox 3. I think it's useful to do
some longer-term thinking about where Firefox and Mozilla technology
generally should be going, even if all such thinking isn't going to be
reflected in the next release or two.

Besides, as I noted in my other post, product innovation and feature
differentiation doesn't necessarily have to be done at the Gecko level
or even the Firefox level; for example, it could be done at the level of
extensions combined with new web-based services, and hence wouldn't
necessarily be strictly dependent on the Gecko and Firefox release
schedules.

Mike Shaver

unread,
Jun 26, 2006, 4:51:35 PM6/26/06
to Bernd, dev-pl...@lists.mozilla.org
On 6/25/06, Bernd <bernd_...@gmx.de> wrote:
> Sherman Dickman wrote:
> > * Should we continue to innovate along our existing differentiation
> > vectors?
> NO, we should not. ;-)
>
> This not a question, but pure marketing speech where the communication
> partners have anyway to agree. Its so obvious that the whole browser
> business is about innovation.

Sherman didn't ask "should we continue to innovate", which as you
point out would be largely nonsensical, especially given a broad
enough definition of "innovate". He asked if we should continue to
push along the _existing_ lines, which I think is a reasonable point
to discuss, though we will probably require a more detailed
exploration of specific VoDs as a basis for that discussion.

Mike

Jon Smirl

unread,
Jun 26, 2006, 9:05:58 PM6/26/06
to dev-pl...@lists.mozilla.org

PI Corp is building something that resembles apps on top of XULrunner.
http://www.forbes.com/2006/06/23/linux_vista_open_cz_dl_0623linux.html?partner=daily_newsletter
http://www.picorp.com/ourtech/ourtech.html

Innovating along these lines might be an interesting direction.

--
Jon Smirl
jons...@gmail.com

Sherman Dickman

unread,
Jun 26, 2006, 10:51:30 PM6/26/06
to dev-planning, Frank Hecker
Frank is correct on both points. Product strategy can help guide
development at any point in the release roadmap, and will be more or
less influential depending upon where we are with each release. But
the goal is to think longer term (Firefox 4 or perhaps 5) and then
work backwards to see what we can accomplish in each release.

I plan on addressing Frank's second point in a dedicated post.
SD

> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning

Sherman Dickman

unread,
Jun 26, 2006, 10:56:08 PM6/26/06
to dev-planning

On Jun 26, 2006, at 1:51 PM, Mike Shaver wrote:

> On 6/25/06, Bernd <bernd_...@gmx.de> wrote:
>> Sherman Dickman wrote:
>> > * Should we continue to innovate along our existing
>> differentiation
>> > vectors?
>> NO, we should not. ;-)
>>
>> This not a question, but pure marketing speech where the
>> communication
>> partners have anyway to agree. Its so obvious that the whole browser
>> business is about innovation.
>
> Sherman didn't ask "should we continue to innovate", which as you
> point out would be largely nonsensical, especially given a broad
> enough definition of "innovate". He asked if we should continue to
> push along the _existing_ lines, which I think is a reasonable point
> to discuss, though we will probably require a more detailed
> exploration of specific VoDs as a basis for that discussion.
>

> Mike

Absolutely. And it would be great to get everyone's ideas on what we
think our current VoDs are, and what they'll need to be in the future.

Sherman

Bernd

unread,
Jun 27, 2006, 1:23:26 AM6/27/06
to Mike Shaver, dev-pl...@lists.mozilla.org
Mike Shaver wrote:
> On 6/25/06, Bernd <bernd_...@gmx.de> wrote:
>
>> Sherman Dickman wrote:
>> > * Should we continue to innovate along our existing
>> differentiation
>> > vectors?
>> NO, we should not. ;-)
>>
>> This not a question, but pure marketing speech where the communication
>> partners have anyway to agree. Its so obvious that the whole browser
>> business is about innovation.
>
>
> Sherman didn't ask "should we continue to innovate", which as you
> point out would be largely nonsensical, especially given a broad
> enough definition of "innovate".
This is not what I implied, but can you really answer the original
question with: No. My statement is you can not.

My suspicion is that there are little down to 0 vectors where we up to
now successfully innovated that we should abandon. The reasons are
twofold: I am skeptical that one will name those areas where we loose
against the competition as vectors of differentiation. Second once you
identify a vector it has already a positive bias which makes it more
difficult to say we should stop this.

Bernd


Axel Hecht

unread,
Jun 28, 2006, 8:36:08 PM6/28/06
to

Having read neither book, I'm curious if new innovation vectors really
make up for disruptive innovations. Let me drop my math jargon here a
bit. Given some n-dimensional path, continuing a differentiation vector
is just leading to a straight line, exploring other differentiation
vectors would lead to a curve, maybe even having a sharp turn. A
disruptive innovation to me consists of really a non-connected path,
with the old path maybe still leading somewhere, and a new path starting
off at a finite distance of the old path and taking new directions from
there. Think SeaMonkey/suite and Firefox as one, and SeaMonkey/suite and
Thunderbird as another example.

From an overall perspective, I think there are differentiation vectors
in some spaces that we can safely keep, lying in the space of users
and/or developers identifying with the product, i.e., the "I love
Firefox" thing. User focus is another. In this space, I think we have
good vectors that are safe to just keep going on.

On a technical detail/feature space, going along the 'tabbed browsing'
route with the same pace may lead to trouble. I would think that there
are points on the graph where you feel close enough to "goal", and are
in the position to see more rewarding new differentiation vectors that
offer a better improvement for the same price.

"goal" is likely a fuzzy enough thing in terms of user satisfaction that
you'll always be able to move and get some customer happy. That's why I
used the 'feel close enough to "goal"' to catch some fuzzy metric.

Dropping some names to the discussion, I think the "Does IT matter?" and
all the commodity software discussion is something we should be aware
of. He's 1D, that gives us still room for good differentiation vectors
in n dimensions.

Axel

Frank Hecker

unread,
Jun 29, 2006, 1:35:14 PM6/29/06
to
Axel Hecht wrote:
> Having read neither book, I'm curious if new innovation vectors really
> make up for disruptive innovations. Let me drop my math jargon here a
> bit. Given some n-dimensional path, continuing a differentiation vector
> is just leading to a straight line, exploring other differentiation
> vectors would lead to a curve, maybe even having a sharp turn. A
> disruptive innovation to me consists of really a non-connected path,
> with the old path maybe still leading somewhere, and a new path starting
> off at a finite distance of the old path and taking new directions from
> there. Think SeaMonkey/suite and Firefox as one, and SeaMonkey/suite and
> Thunderbird as another example.

I can't speak for the "vector of differentiation" theory (because I'm
not really familiar with it), but Clayton Christensen has a pretty clear
definition of what constitutes a "disruptive innovation" vs. a
"sustaining innovation":

Sustaining innovations are directed at existing customers, and
constitute improvement in product features and related characteristics
important to the most demanding customers. Thus, for example, in the
context of email things like better spam filtering, support for multiple
accounts and user identities, virtual folders, and so on, are sustaining
innovations.

On the other hand disruptive innovations are directed at less demanding
and more price-sensitive customers in existing markets ("low cost
disruption innovations") or create entirely new markets, either by
attracting entirely new customers or by enabling new uses by existing
customers ("new market disruptive innovations"). Thus, for example, free
web-based email systems (Hotmail, Yahoo! Mail, Gmail, etc.) are
disruptive innovations, in both the low-cost and new market senses.

However the line between sustaining innovation and disruptive innovation
is sometimes fuzzy. For example, broadband internet access started out
as a sustaining innovation relative to dialup access, given that it was
targeted at the most demanding users for whom the primary
differentiating factor between dialup and broadband was the speed of the
connection. However the "always-on" nature of broadband constituted a
genuine disruptive innovation, since it enabled new uses not previously
possible, for example P2P file sharing and other P2P applications.

> On a technical detail/feature space, going along the 'tabbed browsing'
> route with the same pace may lead to trouble.

I presume you mean that it's difficult to see how features like tabbed
browsing could be further improved, so we're reaching a point of
diminishing returns.

> I would think that there
> are points on the graph where you feel close enough to "goal", and are
> in the position to see more rewarding new differentiation vectors that
> offer a better improvement for the same price.

A good point. However I also think there are other areas where
incremental improvements may continue to pay off, especially areas
important to web application developers, extension developers, etc.,
such as performance, stability, and standards compliance of the
underlying "platform" on which they're building.

> Dropping some names to the discussion, I think the "Does IT matter?" and
> all the commodity software discussion is something we should be aware
> of. He's 1D, that gives us still room for good differentiation vectors
> in n dimensions.

I think the main implication of the "Does IT matter" discussion for us
is that even for businesses more and more applications will be out "in
the cloud", i.e., provided by external providers on a "software as a
service" basis. This will put heavy demands on browsers and
browser-related technologies as the main access point for such applications.

Jon Smirl

unread,
Jun 29, 2006, 1:57:12 PM6/29/06
to Frank Hecker, dev-pl...@lists.mozilla.org
On 6/29/06, Frank Hecker <hec...@mozillafoundation.org> wrote:
> However the line between sustaining innovation and disruptive innovation
> is sometimes fuzzy. For example, broadband internet access started out
> as a sustaining innovation relative to dialup access, given that it was
> targeted at the most demanding users for whom the primary
> differentiating factor between dialup and broadband was the speed of the
> connection. However the "always-on" nature of broadband constituted a
> genuine disruptive innovation, since it enabled new uses not previously
> possible, for example P2P file sharing and other P2P applications.

You're describing what is often called an 'enabling technology'. For
example you could have invented the www in 1940 but it couldn't be
built until the enabling technology of the Internet was in place.

Enabling technologies are a problem in the patent system. People
patent applications based on enabling technologies as if they were new
inventions. But lots of times they aren't really new concepts, they
were just concepts that were blocked because the enabling technology
was missing. This led to the jokes about adding "on the Internet" to
any old concept to make it patentable.

--
Jon Smirl
jons...@gmail.com

Frank Hecker

unread,
Jun 29, 2006, 2:18:13 PM6/29/06
to
Jon Smirl wrote:
> You're describing what is often called an 'enabling technology'. For
> example you could have invented the www in 1940 but it couldn't be
> built until the enabling technology of the Internet was in place.

An excellent point. In this regard I'll play devil's advocate and claim
the following: In terms of Firefox and innovation, the major story for
the future will be the use of Firefox/Mozilla as enabling technology for
other applications and services, Given that, our primary focus should be
on improving the ways in which Firefox and other Mozilla products and
technologies can be used as enabling technologies, as opposed to looking
primarily at end-user features of the browser itself to provide
differentiation.

Jon Smirl

unread,
Jun 29, 2006, 9:21:07 PM6/29/06
to dev-pl...@lists.mozilla.org
On 6/29/06, Frank Hecker <hec...@mozillafoundation.org> wrote:

XULrunner is an enabling technology. It lets you build downloadable,
sandboxed web apps (something that Java should have done for the
desktop but it failed). Some app built on top of XULrunner is going to
be a disruptive innovation but we don't know which one it is yet.

It would be constructive to try and figure why Java failed for desktop
apps. I think XULrunner will succeed because it combines the browser
and the web app platform. Java was missing the browser piece.

So, if you go along with this line of reasoning, Mozilla should
aggressively pursue developer tools, documentation (books too) and
technical evangelism around the XULrunner platform. You don't want
that disruptive innovation occurring on XAML instead of XUL. Capture
the killer disruptive app and everyone will download the platform.

If first class tools and documentation are available for XULrunner it
should make it easier to capture more of the proprietary corporate
market. But the proprietary nature of intranet apps means that they
have no network effects and each company needs to be convinced
individually.

--
Jon Smirl
jons...@gmail.com

Myk Melez

unread,
Jul 5, 2006, 5:18:47 AM7/5/06
to Frank Hecker

Improving Mozilla technologies' utility as enabling technologies is
important, but there's still plenty of important innovation possible for
the end-user features of the browser, and it's important that we do
innovate there, and in vendor-neutral applications generally, because
our users will be better off with such interfaces than with applications
that lock them in to specific service providers.

In some cases other organizations might provide such innovation (f.e.
Songbird for the music web), but that won't always be the case, and we
should be prepared to do it ourselves when doing so serves our users'
interests.

-myk

Jon Smirl

unread,
Jul 5, 2006, 11:21:24 AM7/5/06
to dev-pl...@lists.mozilla.org

I would expand the perception of what is a user. The narrow definition
is the browser, the broad definition is the XUL platform with the
browser being one of many apps on the platform.

Defining your business has been an age old problem. Does the company
make plastic sandwich wrap or is it in the food preservation business?
If you are in food preservation you can make aluminium foil and
baggies too (possibly with different brand identities). In the long
run the diversified view usually turns out to be better, it prepares
you for unforeseen changes in the market place that can kill one
product companies.

Another variation on this is to split the market up into end user and
OEM. Songbird would be an OEM customer. OEM's can be extremely
important, for example Microsoft's entire business model is built
around the OEM channel.

On a related note, how is branding handled for OEM's like Songbird?
Are they free to do what they want or will attempts be made to define
a brand look and feel for XULrunner based apps? The are a lot of
advantages to creating a brand around the platform.

--
Jon Smirl
jons...@gmail.com

Gervase Markham

unread,
Jul 13, 2006, 10:58:04 AM7/13/06
to
Jon Smirl wrote:
> It would be constructive to try and figure why Java failed for desktop
> apps.

Here are some suggestions:

* Lack of promised "write-once, run anywhere"
* Lowest-common-denominator GUI system, so everything was ugly
* At the time, it was slow
* Lack of market penetration of the runtime, which was a large download

> I think XULrunner will succeed because it combines the browser
> and the web app platform. Java was missing the browser piece.

I don't think it's a "browser piece" that's needed /per se/, so much as
an easy way to write pretty and functional UIs.

Gerv

Eric Shepherd

unread,
Jul 13, 2006, 11:02:25 AM7/13/06
to dev-pl...@lists.mozilla.org
I agree with this. Java was (and generally still is) really bad for
writing applications that look good on any platform. XUL is much
closer to being capable of this, and will be much closer yet in the
future.

Eric Shepherd
Technical Writer
she...@mozilla.com

Benjamin Smedberg

unread,
Jul 13, 2006, 11:12:06 AM7/13/06
to
Gervase Markham wrote:

> * Lack of market penetration of the runtime, which was a large download

The large download by itself is certainly an issue, but more than just
download, it was (and is!) very hard to deploy Java applications. Very few
apps written in Java have taken the time to get a native win32 installer
(which will go download the JRE if it's not already present on the system).

One of the key features that will make XULRunner an attractive development
platform is the developer kit tools that will make it easy to deploy windows
installers, stub installers, and mac packages from a xulrunner app. Most of
this work is not done yet (and is at risk for the 1.9 cycle). See
http://wiki.mozilla.org/XUL:Installation_Story for some verbal mockups of
installation sequences.

If we do XULRunner right, the typical user shouldn't ever know that
XULRunner is present on the system or that any particular app is using it.
The only artifact of installing Firefox 3 with XULRunner would be an extra
entry for "Mozilla XULRunner" (or whatever the final name is) in the
Add/Remove programs dialog.

--BDS

Reply all
Reply to author
Forward
0 new messages