We have to be informed and bold to innovate.

Innovators, are by definition pioneers. They set the way, they embrace new technology.

When starting new, deciding on new exciting technology is in some respect straightforward.

Before you begin you need to know what to use, so research the technology available, check out RFCs, and use tools such as caniuse to determine browser compatibility.

See how you can leverage the latest technology to provide the goals for your product (new features, improved performance, etc) =.

Examples of this are; CSSGrid, which replaces flexbox, the defacto layout for Bootstrap. Service workers enable offline content and optimisation, but isn’t yet fully implemented on apple ios (but thats okay!)

But how do we innovate in a BAU (business as usual) environment?

In BAU we have to keep everything as usual, we cannot replace the stack or make too many radical changes, or can we?

As a product development team, we are (hopefully) responsible for the evolution of our products, not just their initial creation, we should be considering new developments, enhancements to improve the user experience and satisfaction.

Satisfied customers are statistically more likely to engage with a product and more importantly, are more likely to recommend your product to others.

So, how.

We must gather feedback from new ideas, customer problems and group them to determine the problems we’re trying to solve, once we’ve done that, we can determine how we’re going to fit in new technology.

If a technology shift is a solution to your problem (i.e. browser compatibility or performance), then we should ensure that our product and development teams can identify key functions (target candidates) which can be separated, then you can evaluate whether you can replace older technology with new via a number of iterative steps.

Obviously don’t suggest change for the sake of it, there should be a user centric goal here, if its a password reset page or a part of the site which doesn’t get used then the 80:20 rule applies, this problem is unlikely to have much impact. Focus on the changes which will impact the most users.

A site who’s content is written in tables, will impact the user experience in newer browsers and be causing a layout issue. If the data is in a database then the team could segment the data so a sub-set could be been replaced with json, formatted into a table structure on presentation. This would enable a range of browsers to be able to serve the content correctly enhancing an experience.

At Render Conference 2017, Eventbrite explained that they had idnetified a problem with performance and extensibility and were looking at ways to improve.

Their application was written on a ruby framework, to improve performance their team looked to implement React, however their CMS was based on Ruby and at the time couldn’t handle node.js to interface with the React elements. They wrote a React render gateway that was able to be queried and this allowed them to gradually replace the framework and the limitations they once had.

To summarise.

After determining a consumer problem, its important for Product and Technical teams to discuss solutions. The product team should be aware of the structure, and its components to understand limitations and future development potential.

The product owners and the technical teams are the pioneers driving the product forward using the latest technologies and innovations working closely with the technical team.

When we build systems we should consider the frameworks, open source applications and the latest technology, we should consider how it will fail over on older browsers and not be too concerned if its not exactly as you designed it, old browsers will be replaced, new browsers will become popular. If you stick with “tried and trusted deployments your product may be outdated faster than you may think”