Tag Archives: business software

Should software vendors use social media for product development?

Social media is a great environment for marketing, communication, customer service, and pretty much anything related to customers. Some companies even use it for product development by gathering their customers’ needs and wishes using social media channels and analysing the information to improve their offering. They also engage with their customers or anyone who’s interested in their products and encourage them to contribute with idea, feedback, etc. Some examples of companies dong this are: GE, LEGO, Procter & Gamble or Fiat

The advantages of this approach are obvious: companies get feedback that is hard to obtain through traditional surveys, consumer groups, etc. people can vote and choose the best ideas, and they can even collaborate to improve an idea, thus giving it even more value. Despite its benefits, social product development isn’t used much in services industries and very little in business software.

Some of the disadvantages of crowdsourcing are not so obvious. We found a very good presentation on crowdsourcing for product development, which includes a brief comparison of the pros and cons of this approach (on slide 32).

As mentioned in the presentation, crowdsourcing is hard to manage, but that’s usually the case for social media. The main challenge seems to be that you need to understand the crowd in order to really benefit from its feedback and ideas. This is also important in order to decide which are the best ways to engage with the crowd in order to find a balance between the effort required (on your side and theirs) and the expected results.

As opposed to manufacturers or services companies, software vendors may have a few benefits that they could use for social product development. Here are some of them:
– they already have user communities, either formal or not, usually made of people who got together to help each other either with advice or workarounds
– they use help desk and issue tracking software which allows them to gather a lot of information, not to mention that they already have historical data
– they have qualified technical personnel to manipulate and store the data, as well as programmers and DBAs to perform some analysis
– their customers usually have employees with some technical knowledge and probably already implemented all kinds of add-ons and even tools they developed themselves

All these benefits can have little value if the vendor never really encouraged its customers to build communities, if they don’t track issues properly, don’t encourage their employees to engage in activities that are not profit-driven, and don’t learn from their customers. Also, these benefits will not be enough to successfully implement a social product development strategy. Vendors will still need to have a social media presence, engage customers and end users, invest in social monitoring and analytics, etc.

We will try to find a few interesting examples of vendors which actually succeeded in using social media for product development – one would assume that social business vendors like IBM, Jive or Salesforce would all be doing it but software vendors don’t always practice what they preach.

Top 365 predictions for 2014

It’s not easy to come up with predictions that actually make some sense so we created a very easy to use system which allowed us to identify 364 predictions for the new year. The idea is very simple: we combined the 26 rows and the 14 columns in the table below and the result were 364 (26×14) predictions.

The 365th is that no one will really take seriously these predictions, which also has the most chances to become reality in 2014.



Is more transparency needed in business software product development?

We usually learn very little about products and services until they’re officially released. This can be explained by the fact that companies don’t want their competitors to find out about their new products or they simply want to create some sort of suspense which keeps people interested in their new products.

While this may be a good marketing strategy in industries like consumer electronics or fashion and apparel, it doesn’t work so well in business software. Companies spending an important part of their budget on business software would like to know what the vendor intends to deliver in the future besides maintenance, patches, and bug fixes. Still, vendors rarely share a lot of information regarding their future road map and when more details are provided to industry analysts, they are usually bound by non-disclosure agreements.

We don’t expect software vendors to make public all of their ideas and efforts made towards improving their software and services, but we think that they should try to find a way to share their initiatives while keeping the important details confidential. The question is: how?

To answer this, we think that vendors should ask themselves the following questions and see if any of it applies to their product development initiatives:

– Is product development mostly based on requests from customers? If yes, is there a way to share with those customers (or everyone else who may be interested – eg: other customers or prospects) some information about the new features? Most vendors use ticketing systems for enhancement requests but not all of them are transparent when it comes to the management of those requests. There are some who actually close dozens or hundreds of tickets by batch because they realize that they don’t have the time and the resources to manage them. Of course, customers are never told that – they’re actually told nothing, they simply don’t get an answer to their questions. If product development is based on what the company thinks that’s needed in the market, it would be nice to explain how you determined which features are needed and which aren’t.

– What can you share without jeopardizing your product development process? Even though your competitors may know more about you than you think, sharing information considered strategic may put you in a bad position. This is why it’s important to define what kind of information can be share and with whom. When you work with partners and customers testing some new features, you’ll have to share some information with them, but does it make sense sharing it with other people (e.g.: analysts, experts, etc), communities (e.g.: user groups), specialized magazines, etc.?

– What do your customers want to know? While it’s easy to assume what people want to know, the best way to find out is to ask. Some may want to track every single issue and enhancement request they create. Others will only want to know what’s new in any major release. It will be almost impossible to satisfy everyone 100% but the idea is to cover 80% of the requests, which are probably generated by 20% of your customers(following Pareto’s rule)

– What’s you level of commitment to a roadmap and product enhancements? All vendors have good intentions (usually) but they’re not always realistic when it comes to allocating resources and time to improving their products. Also, some of the features that may be very important for a new customer may not be needed by others, so they may end up not being included in new releases. The ideal is to find a balance between promising things you may not be able to deliver and providing no details on future releases.

Since transparency is increasingly important in business, we think that vendors should definitely share more information about their product development initiatives. Again, this doesn’t have to be about shearing secrets or confidential information, but about documenting and sharing stories about new features and how they were created, tested, and implemented.

This type of pro-active transparency can also be helpful when potential customers are comparing various solutions and may require information on roadmaps and future developments. More and more customers are not happy with the promise of a “future release” and consider it a bad sign when vendors are reluctant to share information on their future development plans.


By EFF (Own work) [CC-BY-3.0 (http://creativecommons.org/licenses/by/3.0)%5D, via Wikimedia Commons