December 2007

To start with, the name dimdim looks real cool. It emphasizes simplicity and ease of use. Dimdim is using Amazon Elastic Compute Cloud (Amazon EC2) service to operate its service and uses Adobe flash 9 plugin for all its multimedia apps.

Dimdim on top of it followed the user led product development strategy (Web 2.0!, I hope I am write in calling it Web 2.0). Some of the gaps that they identified by taking feedback from users of best-of-breed products.

  • Slow to respond
  • Needs software to be installed on the attendee side
  • Need for integrated audio

Dimdim has been successful in de-bottlenecking most of the above issues associated with other web conferencing solutions. Alfresco VP, Matt Assay has this to say about dimdim “Dimdim is to webex and web conferencing what sugarCRM is to and alfresco is to sharepoint and documentum: an open source value-rich competitor that should keep the proprietary competition up at night”.

Some of the straightforward advantages of dimdim are:

  1. It is presence aware, and will integrate all other messaging systems
  2. 100% transparency as a company, with 100% open source code, roadmap and technical documentation online.
  3. Ajax-based web meeting console. No client-side application necessary.
  4. They are SaaS and leverage on Amazon’s elastic compute cloud.
  5. Coolest name that one can think of for a web meeting software

Some of the brickbats that you hear about them are:

  1. Not a single working demo on anything but windows platform, and is a little strange for an open source offering.
  2. Scalability is still an issue with dimdim. Their claims of supporting 500 party conference hosted on a single server, is by far probably their biggest statement without really testing. Especially considering the fact that 500 users are on a audio-conference on one server.

I certainly believe that they will do a workaround on all of this and also take into account the compatibility issues related to working behind a firewall etc. sooner.

Based on what I see and hear, dimdim seems to be next thing in web conferencing and I also hope that they dont become an acquisition candidate for the Adobe’s, avaya’s and siemens, for it will strip them of the value that it can add as a start-up.  


Satisified customers are the ones that ensure the success of a business. Having said this, I want to take a look at producteering from the perspective of a service provider that help an ISV build products.

As far as the service provider is concerned, which is typically Outsourced Product Development companies, the customer is the ISV and the end-user dynamics are not involved in their engineering activity. This probably is an approach that is fraught with many pitfalls that may result in the product not being really successful.

In one of my earlier posts, I had written that service providers need to think about customer’s customers (end-users) and this becomes critical towards adding value to the ISV engagement. It definitely becomes essential for the service provider to understand the end-users wants, needs, and desires.

How best can we ensure that the end-users get what they want, as customized and as quickly as possible? This can be achieved only by involving the end-users directly in the engineering process. End-users definitely are the biggest source of talent, engagement, innovation and agility. It becomes imperative to connect to the end-users and those that interact with their end-users stand to reap the competitive advantage.

How does a OPD company do this? Because, their point of contact and exit is the ISV themselves and not the end-users. Primarily, OPD companies need to engage with ISVs at a higher-level and be a part of their engineering team. The best way to start would be asking relevant questions that are connected to end-users feedback. OPD companies should also try to be a part of the professional services team of the ISV in their beta, alpha and interact with the end-users.

Engineering a product, this way, will definitely qualify to being called Producteering 2.0

Most Outsourced Product Development (OPD) companies focus on customer requirements, treat these requirements as god-sent, and try to fulfill those requirements. Is this approach right or wrong?

To say the least, OPD companies that are specialists in Product Engineering (producteering) need to look beyond the customer and at the same time not neglect the requirements of the customer.

OPD companies essentially need to look at customer requirements and the customer’s customer requirements. The difference means long-term success of the software product rather than just focussing on the tactical needs of the customer, just by following the requirements provided by the customer.

OPD vendors can add value to the customer at various phases of development and look at long-term benefits of the software product by engaging themselves along with the core PE (product engineering) group of an ISV. How and where to get involved and how OPD companies can add value depends on the nature of products and the stage at which they are in.

This approach may not be applicable for all product lifecycle services that are provided by OPD vendors and may need to be looked at based on the tactical and strategic benefits that it offers.

Amazon Web Services provides developers with direct access to amazon’s robust technology platform. It offers a variety of web services that allow one to build innovative businesses.

Karthik of Aspire Systems has this to say on amazon’s web services – “For quite sometime now, Amazon has been changing the landscape of SaaS with its offering of Hardware as a Service, Computing as a Service etc – so to speak. Many of these services are in beta but EC2 (Elastic Compute Cloud) and S3 (Simple Storage Service) are quite popular. There are still some reliability issues, for e.g., amazon doesn’t commit to any SLAs but I think these things will be ironed out, as it has happened with other innovative technologies. In fact, there are hugely successful companies that help ISVs in using amazon’s platforms.”

View amazon’s solution catalogue and featured solutions here.

I came across this post in one of the product management forums and also read about it in Thought, I will have this information shared in my blog as well.

Does anyone know of ratios of employees in a product development organization? This is related to the ratios on product managers to engineers to QA to UI designers to architects etc.

Beyone of course, saying that it will always depend on a variety of factors, here’s what Marty Cagan of SVPG has to say:

Engineers: One Product Manager for every 6-10 Engineers

Designers: Think 1:4:8, where one visual designer supports 4 interaction designers, and each interaction designer supports 2 product managers

Architects: It would be 1 architect for every 5-15 developers. The lower-end would be 1 architect to 5 developers, typically for new product development that require hands-on architecture and the higher-end would be 1 architect to 15 developers, typically for ongoing management or developing more stable or legacy technologies.

Product Engineering is not viewed as basic knowledge in Computer Science and Software Engineering Curricula. This still has not received the importance that it deserves. In contract, design in other engineering principles, is centered on product engineering, systematically engineering in desired qualities through successive stages of development.

Towards backing the importance of product engineering, companies like Aspire, where I work is looking at evolving a Product Engineering forum ( where you can contribute and deeply work towards the concept of product engineering.

Your product development effort has been outsourced to an OPD vendor. You think you have strict project management controls and disciplined measurement and reporting of metrics. After all, you have many Gantt charts, graphs, dashboards, and health indices to prove it. Yet your product development is in deep trouble and this scenario is more common than you might imagine. The question to ask is if you are measuring the right things?

Managing an OPD effort is different from managing an in-house effort as you are dealing with another entity whose objectives are different from yours. Even if it is your own captive facility, their objectives may not be the same as yours, and it gets complicated further that their customers happen to be internal people. Defining a proper set of metrics is a great place to start to make OPD a success. People who are best in doing it are the vendors who have expertise in doing it for multiple customers of theirs. This, in turn, can act as a roadmap for continually improving the collaborative effort between the customer and the vendor.

Next Page »