Let’s be really honest with ourselves. We are good, sometimes even great, at coming up with innovative ideas. Occasionally we actually are able to think about the experience first and create an innovative culture that puts human being’s needs just as high as product needs.
However, we really suck at delivering innovation.
Whether you are a designer, marketer, product manager, business, or technical architect, chances are you have experienced that amazing rush of the start of a project where everyone is bright-eyed and bushy-tailed, super excited to design with others that which people may actually use. Or you have started a new agile methodology and can actually see delivering something in 30 days or less, that provides value.
However, sooner or later those 30 days turn into 300 and funding is going to be cut. Or you spend 90 days delivering something only to have it fall flat or worse…no one knows that you delivered it at all.
Yes, there are a lot of potholes on the glorious road to delivering innovation. With multi-year digital transformation projects well into their 2nd or 3rd year at many medium and large enterprises, there is a lot of nervousness in the technology, business, and design corridors that go straight up into the C-suite.
So what’s the problem?
As with anything so big and nuanced, there are bound to be issues. However, the digital transformation space seems especially prone to missteps. And those missteps are really costly. See, millions of dollars have been allocated to these transformation efforts, and yet it’s proven really difficult to align the business outcomes with the technology spend that’s happening. Throwing more money at something never works, yet in the enterprise software world it is the tried and truly failed remediation method.
While the devil is surely in the details, it seems that delivering enterprise software always takes way too long to provide the value we seek. Agile methods actually turn into a waterfallesque quagmire that teams never seem to be able to get ahead of. Devops ambitions die, the victims of antiquated testing approaches. Innovative ideas grind to a halt in the face of competing business and IT groups within an organisation.
Another tried and true method within any organization is tinkering. If a methodology or a practice does not get the results you want, you say it’s too heavy and you tinker. Often the folks that do this are not wrong. However, the end result is that you have a lot of things now prepended with the word “lean” or “agile”. Borrowing heavily from lean manufacturing practices, the spirit is certainly in the right place. We look at what the process is and get really laser-focused on what needs to change to be able to get the outcomes we want. So Lean Digital Transformation is now a thing, applying lean principles to the design, development, and delivery of customer value and trying to do it in a quick way.
Why do we still struggle with innovation?
Delivery of innovation is a struggle, whether we put the word lean on it, mainly because teams focus on the wrong things. Requirements being the centre of that circle of wrongness. Even in an agile design, development, and delivery world, the focus on requirements gets in the way of delivering. It’s a terrible thing, seeing a seasoned and talented team focusing on getting requirements right when they really don’t have a clue about what their customers truly need or want.
When this happens, delivery teams never get to a shared understanding of true business outcomes, outcomes that have a real benefit to the business as well as the customer. If the teams don’t really align on an important business outcome, then what they deliver can never really move the ball forward with regards to innovation. There are three areas where delivery teams get caught up in the death spiral of requirements gathering:
- Focusing on delivering journeys that are too long and/or of little tangible value to achieving a business outcome
- Underestimating the data needed to achieve the outcome they are looking for. Or overestimating it. Either way, that creates delays in the delivery of the product or service.
- Never truly understanding the personas that will be using the systems. We pay lip service to building pretty, well-formatted pictures and we FEEL good that we did our research. However, in the end, we never really know the consumers of our innovative ideas because the personas we developed rely too heavily on the inputs of business and technical folks that have a great track record of never really knowing their customers to begin with.
In enterprise software, there is also this institutional aversion to doing small things quickly, learning from what works, and pivoting constantly. In essence, an aversion to really understanding how to deliver innovation in an agile fashion.
Of course, in the enterprise world innovation is difficult to achieve. To be fair, the enterprise is not set up to realise innovation. The sheer number of people that have to sign off, get involved, have their say, etc can kill innovation in a heartbeat. In most enterprises, innovation is seen as a threat. Something to get excited about on the surface but never allowed to permeate deep into the cultural DNA of the organization. That is one reason why you see so many folks in enterprise organisations leave to go join smaller organisations and cultures so that they can see their ideas come to fruition.
It is said that every great idea needs to fail at least three times before it succeeds. In this hyper “gotta have it now world we live in” a lot of people just do not feel they have the time to allow for that. However, in a truly innovative agile development world, being able to learn fast and keep going is what is really needed.
An Innovation Framework that works
To really deliver innovation, we need to stop focusing on the requirements gathering process and allow leverage design-focused and agile methods for iterative delivery, as well as time to learn what works so that we can be in a model of speed to market and experiential learning.
To do this we need to be hyper-focused on delivering small journeys that provide value, with just the right amount of data to support that journey and the interactions that are needed to support the personas that we truly understand. From a process perspective we need to leverage 3 things:
- Design Thinking
- Truly agile and lean development methodology and
- Low Code application development platforms
Design Thinking
Design thinking does not really need introduction on UXMatters but just as a high-level overview, design thinking is a problem-solving process that combines creative and analytical thinking. In the digital transformation arena, we use design thinking techniques to often really answer “What Problem are we really trying to solve here?” to really drive business transformation and understand the business outcomes we want to achieve. Design thinking is of course immensely popular and is rapidly becoming the backbone of innovation in a lot of business areas.
Agile Development Methodology
Too often, the software that is chosen to implement an innovative vision is simply the wrong software. Chosen for legacy, political, or just plain silly reasons, it becomes abundantly clear that it’s the wrong software simply by having to read a book to understand how to implement it. After you read that book, you then have to hire an army of people to move in with you for 9 months, just to get a login screen and a couple of forms you rarely use.
Enterprise software has come a long way and there are so many options out there, the trick is to truly align the best software to achieving the business outcomes you just spent all that cool design thinking time articulating.
Low Code application development platforms
For those unfamiliar with low-code, it’s pretty much what it sounds like. It’s technology that requires you to code far less and instead configure with visual development tools such as widgets, checkboxes, instant connectors and out of the box templates. The best ones couple them with robust design systems that ensure you never sacrifice the latest design abilities.
Also important is that low code development platforms empower business users and foster a closer relationship between IT and the Business, producing results faster by giving them the tools to dive in and quickly develop solutions to business problems.
Low-code is not just a technology but also an enabler of the design-thinking process so you can drive innovation. This is because you now have rapid prototyping abilities within the target technology you are using. It’s not just pretty pictures or high fidelity prototypes that have to be built anymore. It’s actually part of the product you will deliver.
Delivering Innovation anywhere can be hard. Like anything successful, it requires some planning and coordination to really see that value. To do things quickly and repeatedly requires a shift in mindset and culture. Whether its digital transformation today or something entirely else tomorrow, ensuring that you are outcome-focused will be the key differentiator in delivering results that your customer actually needs
