The Place For Engineering In a Product Roadmap: Why We're Changing Our Front-End Technology

Product roadmaps are typically driven by corporate strategy and customer requests/demands. Roadmap features implemented in the product often introduce exciting functionality, delighting users and enticing potential customers.

Although companies aren’t democracies, good Product teams consider all suggestions regardless of the source. That said, Product Managers may inwardly groan when Engineering makes suggestions. Since Engineering knows where the bodies are buried, their suggestions are best heeded. However, Engineering’s ideas about exciting product improvements seldom conform to anyone else’s ideas.

Engineers get excited about performance improvements that shave nanoseconds off response times. They also love refactoring code to make it less susceptible to bugs. Engineers are passionate about removing vulnerabilities from code and preventing hackers from having a field day.

Yawnsville, right? Product Management listens to Engineering’s suggestions, thinking, “What’s in it for customers? These changes are invisible.” At the same time, Product Management knows that Engineering doesn’t typically suggest work for themselves unless it’s important.

Product Management swallows Engineering’s suggestions like a bitter pill. Although unpleasant, the consequences of not taking one’s medicine are potentially dire. Performance improvements are boring until usage scales to the extent that performance problems emerge. Code refactoring is pointless until the code gets so complex that customers face showstopper bugs that could have been prevented. Closing security holes is crucial until hackers take control and customers lose trust in your solution.

Technology change at KoolSpan

No two words strike more fear in a CEO’s heart than “technology change.” When an Engineering team utters this phrase, the business side envisions months of labor, a permanent “do not disturb” message on Engineering’s door, and ultimately … nothing. Not nothing, exactly, but nothing with any visible change or value. That’s the thing about technology change — it’s typically a change to the bones of the system to make a firmer or more flexible foundation to support future development.

KoolSpan Engineering came armed when they made the case for a technology change. They admitted that, on its face, a migration of the front end to JavaScript from a proprietary sunsetted technology would yield no outward improvements. They claimed that the ubiquity of JavaScript developers would make hiring easier, the maturity of the language would facilitate faster development, and our iOS, Android, and Windows platforms could all share the same code.

When Product Management awoke from their naps, Engineering unveiled its big gun. One of the other benefits of such a popular front-end technology is the active open-source projects available to them. By aligning with one of these open-source projects, KoolSpan Engineering could use the framework of a new whiz-bang user interface with little effort. Furthermore, the open-source project’s user interface contains a rich feature set for the taking.

Finally, Engineering casually tossed out another enticement – the technology change facilitates support for Mac OS clients.

KoolSpan TrustCall v. 11

Now that Engineering was speaking Product Management’s language, they started listening. Instead of finding new features and fixes to delay Engineering’s prolonged development period, Product Management worked to clear the field so Engineering could get to work. Consequently, TrustCall v. 11 is on the horizon, with its first release expected in Q4.

TrustCall v. 11 will be a win-win-win — Engineering will standardize on a popular technology with myriad benefits, Product Management will have a release with enough beauty to delight current customers and attract new ones, and customers will rapidly receive new features they’ve dreamed about but didn’t expect until much later.

CTO

David Asch