The first is a simple HR issue. We have recently added a new fellow, Lee Garrison, as VP, Products (separately, we are very excited about Lee joining us. He brings a bit of a different skill set than we have had in the past). The client code migration path, and communicating it, falls into his area of responsibility. He just started on Monday and understands quite well that this is on his plate for quick turnaround.
The second is how much or how little to communicate. Do we talk about what we are planning to do next week or next year? My preference is always to give you guys as much visibility as possible, but the longer the time horizon the bigger and more complicated the communication becomes.
A lot of work has been done on this issue internally. It is just not yet visible.
I don't want to commit Lee to a date on his third day in the office, but it will be soon. Robert, if there is a specific issue that you are wrestling with please speak to your rep or let me know offlist and we will see if we can get you the info you need to make a decision, or the resources to help you with something.
I know this is not the answer you were looking for, but I hope it helps.
Regards
On Wed, 7 Apr 2004 07:05:10 +0100 "Robert Macleod" <[EMAIL PROTECTED]> wrote:
Hi Elliot,
Are you now able to share the plans for the client code with us ?
Regards Rob
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of elliot noss
Sent: 05 February 2004 22:26
To: Todd Jagger
Cc: [EMAIL PROTECTED]
Subject: Re: Managed DNS Service concerns (tangent)
Ok. Time permits.
First, I want to talk briefly about client code and RWI. We are, I am,
in complete agreement with the comments made. The one thing that I want
to make sure is clear is that these items are not being ignored. We have
spent lots of time and lots of money (little of it well) on these two
issues. In any organization some things go well and others go, um, less
well. These two are right at the bottom of my personal list. There have
been too many statements unfulfilled on these two items and I do not
want to add to the list. I will say folks are working on these things
and, especially with client code, I will be unhappy if you do not see a
clear plan shortly (within a month?).
Next, with regard to the level of new services. I personally do not
agree with the comments below in a couple of ways. When OpenSRS was
first introduced it was (quite good) beta code. The original designer
chosen did nothing but make pretty pictures for a few months and we had
to switch all of our plans. We had signed contracts and we had a market
moving at a million miles an hour. We pushed this baby bird out of its
nest quite early.
The point of all that is that the level of new services launched today
is miles ahead of when we first released OpenSRS and 100's of yards
ahead of where the first certs release was. IMHO, each release of a new
service is a little better than the previous.
And SO WHAT. None of that matters, because if there is one lesson we
have learned and learned well is that we will always learn more in the
first six months being in the market than we ever will just talking with
customers and whoever for whatever length of time. If you would rather
someone else sand off the rough edges so be it. I would suggest that
offering a service early provides two HUGE advantages for you. First, it
allows you to participate meaningfully in the evolution of the service. Second, it allows you to learn how to market the service. IMHO, there is
much more impact today in the way a service is marketed (and by this I
mean all elements, bundling, pricing, packaging, not just where you
stick the link or what keyword you buy) than in its features.
As for your input, there is an extremely high level of involvement with
customers at all stages of planning and design. Don't believe me? Speak
to your rep and ask to get involved. Anyone willing to be demanding is
welcome. Many, many of you have participated in surveys, in placeware
sessions, in one-on-one conversations with product management and sales
and in the NSE program. Again, this pales in comparison, no matter how
well done, no matter how much done, to being in the market.
Lastly, wrt the comment about the process being used in the development
of blogware vs the development of dns, there are some important
contextual differences. They are not what I want to comment on though. Rather I want to highlight that we are learning not only about each new
service, but also about the process of developing new services in
general.
Each time we do it we try and do it a little better. We hope to learn a
little more from each introduction. The approach we took with blogware
was much different. Your feedback there is helpful. We will try and take
the best of each process and leave the worst. It will never be perfect,
but our goal is that it just always be a little bit better.
Be assured, with every thing we do your feedback is what drives it. When
it doesn't seem that way please remind yourself that you all provide
feedback in a number of different ways, meaning no one of you hears it
all, and listening to everyone will NEVER mean pleasing everyone. By
definition.
Thanks for this. It is a great post.
Regards
Todd Jagger wrote:
Hello,as well.
Pardon me for inserting this extrapolated tangent into this thread, however Rob's statements I think deserve some (more) discussion here as they pertain not only to the DNS service but other Tucows products
Let me preface by saying each of us has a different business model, needs, goals, customers, etc. What may be critical to one may be unimportant, or even undesired, by another, and vice versa. Tucows can't be everything to everybody and they have a significant challenge
in trying to tailor their offerings and services to a vastly diverse customer base. While any endeavor has room for improvement I think overall Tucows has done an exceptional job and, above all, stayedall.
consistent with high standards of ethics and professionalism. In addition they overall seem sincerely interested in what we want. Sometimes they also appear to ignore what we tell them, but at least they're listening. ;-)
Whether or not Tucows offers X service or Y product is not the topic here. Tucows is going to offer the products and services they determine; that is their prerogative, just as ours is whether or not to resell that service or product, or to do business with Tucows atTTL.
What concerns me is the development these products are given and the level at which they are offered. It seems in each case we're given something one or two notches shy of a kick-ass product, and that directly impacts our abilities to sell them to our customers.
To use Rob's example, the DNS service without the ability to configure
And the apparent stagnation of the client code interface and RWI. We
resellers have been bemoaning the state of the client code and RWI usability for literally years. The latest word is that new client code is important and probably 6+ months down the road. I remember that same "official word" perhaps 2 years ago, back when the SF client
was the model on which the client code was to be built. Specific bugs
and suggestions have gone unimplemented. (Does the client code currently require a payment method - e.g. credit card input - for renewals? This was the first reason I went to the SF code. We don't want to keep numbers on file, customers' credit cards expire or they change cards or addresses; what is Tucows's model for getting payment on renewals? None apparently from the client code.)
The email product has the potential to be a great outsourced service for those of us that offering fits our needs (mine does), and while some of the product are excellent, it falls short of being superior on
multiple levels. The new feature additions are an improvement but don't quite take it to the A list. The webmail interface is still clunky, even compared to something like Squirrelmail, and doesn't even
come close to the web interface of Cyrusoft's SilkyMail. And besides,
how many people want to use webmail for their primary mail client? Not many I know. My clients want the features to be usable from their
email client, and the webmail is something to use when they're not attheir computer.Features like the shared address books are great but aren't going to mean anything to my customers unless they can share them from a mail client. There's no mention of the protocol (is it LDAP? ISMP? ACAP?me.
or something proprietary from Stalker?) There are many other issues, some of which I've raised, and Bruce & Peter, you know how to reach:-)given
The point here is that with core reseller products it seems we'rea less than complete, and thus less than competitive, solution. It almost seems that the products (at least the Email and Managed DNS) were determined prior to extensive discussion about what resellers needed/wanted in the offering, and now that the products are out there
it might be difficult or impossible to mold them to what our customers
need. This leaves us in a difficult position of either offering something we're not excited about, or not offering it at all.
This is in stark contrast to what's going on with the Blogware development. That product is being tested, hammered on, Bugzilla'ed, discussed in detail, and most importantly modified to what the resellers want. I'm convinced it's going to be, already is really, a top-notch product that's ahead of the curve, not behind it like Email,
Managed DNS, client code, RWI.products
IMHO, I'd really like to see Tucows re-tool the quality of thein the same spirit they're developing Blogware. Remember guys, thisistechnology --- you don't want to be playing catch-up.
Thanks for listening tj
-- Elliot Noss Tucows Inc. 416-538-5494 enoss.blogware.com
