competition1Add my vote for this tag customer_focus2Add my vote for this tag process1Add my vote for this tag usability2Add my vote for this tag create new tag
, view all tags

Market Driven Innovation

(yet to be defined process of TWikiCommunity to be more market driven)

-- Contributors: PeterThoeny - 06 Feb 2006


Personally I think we need to be more focused on the market. It is also important to be engineering driven, but we currently operate too much on the engineering side.

Having interviewed Alcatel, AT&T, HP, Intel, Motorola, Nokia, Novell, Sun Microsystems, Yahoo Inc and a bunch of other companies for the WikisInTheWorkplaceBook, I think I have some ideas on how customers operate and what they need. Nevertheless, I have seen that some of my market driven proposals have been rejected by the community - as I see it - because of developer centric views.

Lets use this topic here to brainstorm on how we can drive innovation of TWiki with a market focus. LynnwoodBrown had the idea to establish a market focus group that compiles the market requirements and reports that to the development community.

-- PeterThoeny - 06 Feb 2006

Innovation is the delicate balance of market pull and technology push. No question they should be balanced more.

-- ArthurClemens - 06 Feb 2006

"Market" seems to be a difficult thing. All those companies which use TWiki - they are sort of the market, aren't they?

I have some sympathy with the original TWiki mission statement. I have to, to justify my own decision: I have chosen TWiki in favour over other Wikis because I have been looking for "web-based collaboration platform targeting the corporate intranet world". And I admit that I've cursed a couple of times because of some changes which were made in the late stages of Dakar. But still - I've cursed under my breath, to be sure that CrawfordCurrie and the others TWiki contributors would not hear it. Because what were the options? Who of the "corporate intranet world" would step in and take over the work of the development community?

The driving forces for developers are (1) fun and (2) money. I have to say that it doesn't contribute much to my fun of software development when I know that the function I'm writing might be going to be used behind some firewall, in an intranet, by some remote company, whatever famous. We know who the development community are, and I think they've made appropriate suggestions where they think compensation for their work could come from.

During Dakar's test phase we have seen one example where someone working for one of the companies interviewed for the book got involved, and he has contributed a lot of his time. And eventually, some of his requests have been honored.

I'd really love to see a focus of TWiki development on intranet collaboration, for my very own purposes. But this needs more involvement of the companies sharing the same interests. Compiling their requirements in a market focus group can help. But only if they understand that a market is both Supply and Demand. If the market focus group can't create some sort of "supply", then their demant won't generate any revenue (code in this case). It will be like Dakar again: Codev is the market, developers create supply - for developers' demands.

-- HaraldJoerg - 06 Feb 2006

nicely put Harald - I wish i had a good way to express the fact that to me, users like LynnwoodBrown and MichaelDaum are much more important (in an open source way) than Google, simply because they are involved where Google is not. With open source you only get what you put in.

(I only single out Google as an example of a large company that uses TWiki, has only recently revealed it)

-- SvenDowideit - 07 Feb 2006

Nicely put Harald, some developers think that compatibility is less important than a cool new design. TWiki's future success depends on innovation with compatibility in mind.

-- PeterThoeny - 07 Feb 2006

TWiki.org is its own best customer. If the TWikiCommunity can show that it does well for TWiki.org then others will see this is promising for their own cases too. Don't get it wrong as a community being too self-referential and self-absorbing. But there are a couple of things that can be done better to increase TWiki's impact on the market and vice versa. If that works out "supplies" for "demands" will follow, that is people invest money and effort to get the innovation done that they want. For instance: TWiki.org needs a relaunch, first class TWikiApplications, showcase installations, a TWikiRing etc. This is all non-technical but important to show scalability of its own business model.

-- MichaelDaum - 07 Feb 2006

See also: TWikiApplicationsShowcase

-- ArthurClemens - 07 Feb 2006

In this light, read Signal vs. Noise: Essential vs. Non-Essential

-- ArthurClemens - 07 Feb 2006

Certainly the TWikiCommunity and TWiki.org should be a good showcase, there are ways to improve that.

Do not forget that community members are by definition TWiki administrators, developers and also users. That is, it covers just part of the stakeholders of a TWiki deployment. In particular it typically does not include the decision makers for introducing new enterprise tools. I think it would help the community if we introduce Personas to illustrate the different stakeholders, such as TWiki administrators, entry level users, power users, application programmer, non-technical users, managers, and IT directors.

-- PeterThoeny - 08 Feb 2006

or as a counterpoint idea: It might help TWiki to remove things rather than add them - a part of the problem we have with the twiki.org site, the documentation and the code is that we keep adding things.

Instead we could work to simplify, reduce the clutter.

-- SvenDowideit - 08 Feb 2006

I think you have to be realistic about this. TWiki is not a product in the classical sense. There are no sales or marketing departments. Developers work on what they want to work on, either because it interests them, or because they need something for their environment. The best that you can hope to do is lead, guide and encourage development directions. Anyone who attempts to dictate is doomed to fail, as people will simply walk away.

So, how can you guide such a disparate developer group? Only if everyone can see where TWiki is headed will they become motivated to contribute and work together to keep it on course. Of course, you could simply ssay "it's finished", in which case people will know to walk away and find something more exciting to do instead. That's basically what happened some time after Beijing, up until 8 months into Dakar.

The keys to maintaining a dynamic environment are IMHO roadmaps and prioritisation. A roadmap tells you where the project is headed, and priorities tell you what has to be done to get there. Customers need to be involved at all levels (there are many different kinds of customer) from putting together the roadmap through to day-to-day prioritisation (Kenneth has been invaluable at this level).

I have been working off my personal roadmap for the 16 months or so. A few others have also put forward their personal visions. Please take this as a challenge to the rest of the community - and especially to you, Peter - to put up a personal roadmap that fits your vision. The same challenge applies to all customers - representatives of "the market" - even those who don't directly contribute.

Lynnwood has previously offered to facilitate extraction of a project level roadmap from these personal visions. Perhaps the offer still stands. On the other hand, it would make a lot of sense to try to have someone without a vested business interest do this facilitation.

-- CrawfordCurrie - 20 Feb 2006

Related to this is a CustomerFocusedTWikiOrg website.

-- PeterThoeny - 10 Mar 2006

Quoting Peter: "some developers think that compatibility is less important than a cool new design". What does compatibility mean? Does it mean that one must maintain code architecture that is no longer the best way of doing things (assuming that is ever was)? Does it mean that all existing topics should continue to work with an indefinite number of future releases? Or does it mean ensuring that there's a reliable script that will turn old TWikis into new ones that work with an architecture that's far better designed?

One of TWiki's main features is also something that makes the issue of compatibility trickier than with many/most other wiki implementations. Once you've moved beyond the simple text markup of basic wikis and into powerful functionality like %SEARCH%, it's no longer a matter of gently massaging text files to maintain compatibility with new versions. But does this mean that TWiki must forever live with the current overfeatured and hideously slow %SEARCH%, which currently supports approximately 26 arguments!

Clearly TWiki can't abandon its current users. At least I think that's clear. Many companies have apparently built up large repositories of documents and are relying on TWiki to continue to work. Equally clear, however, is that the current implementation does not scale well.

This is a problem on at least two fronts. First, how does one manage a huge number of topics so that things can be found and organized, preferably with some sort of automated organizing tool? Tags are one thing that are being explored to handle this, although I think it's become pretty evident that manual tagging alone is unfeasible once one has a large number of topics. (Manual tagging is far more feasible with a new install with cooperative users.)

Second, what technical changes have to be made to the engine so that large TWikis don't come to a grinding halt? There have been numerous reports of TWiki sites performing far more slowly under Dakar than Cairo. The only difference I have any real knowledge of regarding the two is that Dakar is far more object-oriented. I find it hard to believe that that is the explanation for such a marked slowdown and, if it is, that says something about the language, not the methodology.

I don't have any good answers to offer at the moment. Compatibility can't be abandoned, depending on how one defines the term. But new ideas that offer notable performance or other useability gains oughtn't be dismissed just because they're new or because they present compatibility challenges. A "compatible" twiki that is too slow to use and too hard to navigate is just as bad as a new engine that renders obsolete the current topic.

-- MeredithLesly - 10 Mar 2006

Having stumbled upon this topic again, a thought struck me: market? Generally speaking one thinks of a market when one is selling a product. While I know that a number of the folks here make money by creating TWiki sites, that's very different from a number of people getting paid by a company to produce a product that will be sold (hopefully thereby justifying said people's salaries).

-- MeredithLesly - 22 Apr 2006

Interesting topic; shame the fire seems to have gone out from under it. Nobody else got any ideas?

-- CrawfordCurrie - 22 Sep 2006

See recent research done on TopThreeFeatures customers would like to see.

-- PeterThoeny - 06 Nov 2006

Of course we will not fall into the trap of featurism (famous for Microsoft). See the Getting Real by 37signals, with this article: Forget feature requests.

-- ArthurClemens - 06 Nov 2006

Edit | Attach | Watch | Print version | History: r19 < r18 < r17 < r16 < r15 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r19 - 2006-11-06 - ArthurClemens
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.