While working for many years with software product managers and small / mid-size ISVs, I have seen time and again companies falling into traps on their way to new product development. Here I am trying to summarize some of those traps in one place:
1 - Thinking too big - ‘Put all bells and whistles in first version’
"We don't want to let client know what we are up to, we will surprise them"
"We have enough experience, we will just go to the market with a full version with all the features"
There is always a lot of excitement at the beginning of a product cycle. Everyone, especially a product Manager, wants to give a killer, cutting edge, next generation product that will leave the competition in dust and make the this product numero uno in the market. This is the most common trap many company fall into. Partly because of the pressure of higher management, or sales & marketing folks, product management just tries to include all the features, bells and whistles in to the product at Release 1.
Such approach, thinking too big, eventually leads either to delays in product cycle or inferior quality or both. A better approach, instead, could be to start with a basic functionality first. Make the product work and let it do its core (only) function successfully with few basic, select additional features. Simple. Nothing complex. Rather than adding all the features, time and attention should rather be provided to evaluation, validation and experimentation of latest technology, platforms, scalability and ultimate user experience.
2 - Wrong adaption of a Global Model
Developing everything in-house, outsourcing an entire product development and applying in-correct global strategy all could potentially lead to high product development costs or inferior product.
- Using offshore-only provider - All you are getting is a cheaper programmer with no meaningful on-shore collaboration. You should instead tap into a glocal (local consultants with global efficiencies) providers such as my company.
- Doing all in-house - Easier to maintain and implement, but you limit fresh ideas and product cycle efficiencies.
- Outsource everything - your company needs to adapt to a product than other way round. This is most risky approach.
- Keeping Testing in-house - It has been proven that software testing is generally a non-core task of the product development cycle and often better accomplished by outside party. my company has large customer base where we do only testing of their product.
3 - Work with offshore only provider (outsourcing 1.0):
“We are only looking for programmers at lower cost.”
“We have this existing relationship and we are set with them.”
When you hear yourself saying “we are set”. you really are in need of a fresher perspective and newer vendor. Offshore only providers often don’t have their roots in US. I sometimes call them utility companies. They don’t hear, see and experience same things that you and your client does and thus lack perspective necessary for deeper collaboration and better product development. Lot could be said on this point, but key is that you will have much better product if you collaborate with a vendor that is local to you or local to product’s end market, and also could deliver efficiencies associated with global model.
4 - Keep everything in-house:
“We do everything in-house”
“We have never worked with outside vendor. We have all we need.”
This strategy is easy to manage and often perceived as faster to implement. The downside of this strategy is that product team does not get outside ideas and perspective. There are many outside companies who may have done done good groundwork, framework which could be beneficial to your product. You could also tap into their experience of working with other product companies similar to yours. But by keeping everything in house you are limiting yourself from any such ideas and experience.
5 - Outsource everything - Even innovation?:
“We want you to develop a complete solution for us. do your own R&D”
“You figure out the what, how and which technologies, methodologies and algorithms. Just give us a product that meets our requirements.”
This is a commonly followed approach in smaller companies where they lack technology resources to developer a new product. An outside company may not know your client base as well as you do and, furthermore, they may not have as good innovators as they may have developers. This approach should be avoided in all circumstances, especially when you are developing a new product. Such companies should seriously consider partnering with a local consultant who also can also bring global teams to the product development.
6 - “Do it just like how the old application does”
“It should work exactly like how the old app works. No changes at all!”
“Why would anyone want to do it differently, I don’t understand.”
This is a common mistake for companies that already have an older product out in the market and intend to re-engineer the same to the newer technology. Part of the reason of this strategy is customers are already familiar with the product and company don’t want to lose those customers because of newer product. You need to understand that while you can maintain same functionality, fundamental user experience should not necessarily be the same, it could be much better. After all, you want your next generation product smarter, scalable and simple.
Once I worked with a company that was working on a new .NET version of their legacy product. The only requirement, often, that was provided to the development team was a screen-shot of an older COBOL based system. “Here do it just like this one” was often the whole requirement. Needless to say that, this product didn’t turn out as expected.
7 - Minimum client involvement
“Let’s wait before we let them know what we are up to.”
“Let’s surprise them with the new version, instead of taking their time now”
I have seen many companies developing a product in relative client isolation i.e. without a client involvement. This is where higher management needs to step in to invite some of the key clients in and have them their say in the product’s newer version.
Recently I was talking to an CEO of a product company. Among many things, we were discussing client participation in the new product release he had planned. He, refreshingly, surprised me when he said they wanted to build only a small skeleton version first and take it to the road show with potential clients in turn asking them for their participation, feedback for next versions.
This is the best approach for a product development and also to ensure client acceptance to the new version.