Implementing new technology in the product is a task that often stymies software companies. Because the change frequently goes to the very core of how the software works, and developers are on unfamiliar ground, there is lots of potential for your company to get stuck delaying the use of new technology year after year.

The key difficulty is that software is made out of technology, so changing the technology it uses – such as migrating to a new platform, transforming to object oriented code, or cracking open a product to work with many standard databases – is the equivalent of making a manufactured item out of new materials, say, going from wood to composite plastic.

If you decided to switch to building a product out of a new material, the engineers would be hesitant to launch into the initiative. The uncertainty of the outcome would make them unwilling to make a leap of faith, hoping they’d land safely on the other side.

This makes sense. Leaps of faith aren’t good engineering.

Yet there is a way to approach technology changes so that engineers can get started, keep moving, and break through to the other side. A Product Manager can serve a pivotal role in successfully implementing this approach, through requirements, so that the product takes the technical lead over the competition, and continues to widen the gap.

Read on for an explanation of this approach.

[private]

Uncharted Territory

You can use the approach described here not just for new technologies, but for all areas that represent uncharted territory for your development staff. This could mean a new way of programming an existing feature in the software, or functionality that demands very different programming tasks (for example, adding transactions to what has so far been only a reporting tool).

Make It a Research Project

First and foremost, when you need to explore a new technology as part of new functionality, take the heat off the developers. Submit a requirement for a research project to try out ways to accomplish the task and then select the one that works best.

Often when a software engineer is asked to create a capability involving unknown or untested technology, their response is: “But we don’t even know if the approach we have in mind will work, and we can’t accurately estimate the time needed to develop it.”

This is why it’s so important to position the requirement as a research project. It gives the developers official permission to be uncertain, and to play with different designs and try different ideas.

It’s Applied Research

However, this is applied research. If the research project identifies a successful way to implement the capability, if it can be done within the time allotted for the project or with the addition of a little more time, then by all means put the new feature in the release. The focus of the research is a practical, specific outcome. You are not required to throw away the time spent on the research project if it can be put to use right away.

So often with adventures into new technology, the solution turns out to be a whole lot simpler than all the original concerns may lead you to expect.

Always Allocate Research Time

Technology is always changing and progressing. Standards are continuously progressing and being refined. With each new release of a programming language, new programming tactics become available. Therefore the effort to apply new technologies and explore new programming methods and tactics should be ongoing.

You can’t stop, or you’ll wind up falling behind.

Just as you would allocate a certain percentage of development time to fixing bugs, you must allocate a certain chunk of time to research projects. Don’t let a release go by without one or two research projects.

But Set Time Limits

With teams of skilled, detail-oriented engineers, it’s easy for the fascination of new technologies and solutions to draw them off into long exploratory projects that never end, where the answer to one question leads to another question.

The point of the research is not fun or knowledge for knowledge’s sake. Therefore, set time limits that focus the project on simple, contained efforts. A duration of two to three weeks would take care of most of the possible research efforts called for to advance the product.

There Are No Guarantees

It’s important to understand that depending upon what developers discover in their research, there may be nothing usable coming out of the effort. That’s okay. The engineers will have learned, at the least, what doesn’t work. Or they may very well learn what works, but unfortunately for one reason or another the results are throw-away.

It’s a great outcome if at the end of a research project, the team understands what will work to solve their problem, and has a clear idea of how to estimate the time required to do so in the next release.

The Only Way to Learn Is to Try It

With new technologies, programming commands, and tactics, the only way to learn is to try it. Product Managers may need to provide plenty of encouragement and support to change the mindset of programmers – used to meticulous accuracy and predictable results – to a more adventurous, exploratory one.

People are used to looking to experts to answer their questions and provide useful advice. But with technology changing so fast these days, you may find that your product is a pioneer in the use of new standards and architecture. Or you may be applying relatively young technology to a whole new area.

Move Forward With What Works

The outcome of 95% of research projects should be a clear understanding of both the best method to accomplish the goal and the effort and resources required to do so. (The outcome of the other 5% is knowing only what doesn’t work, and knowing what research project is required for the next release to continue trying to solve the problem.)

This outcome feeds into the requirements for the next release. Development has the information it needs to estimate and plan its work, and Product Managers can listen to the results of the research and determine the project’s priority in the next release.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]