Let’s be really honest with ourselves. We are good, sometimes even great, at coming up with innovative ideas and really cool features and functions. However, only occasionally, despite our best efforts, are we actually able to think about the experience first—let alone create an innovative culture that places human beings’ needs at the same level as business needs.
Moreover, we really suck at delivering innovation. Whether you are a UX designer, marketer, product manager, business leader, or technical architect, chances are you’ve experienced that amazing rush at the start of a project when everyone is bright eyed and bushy tailed because you’re super excited about designing with people who might actually use what you’re designing! Or you might have launched a new agile methodology that would enable you to deliver something that truly provides value in 30 days or less.
But, sooner or later, 30 days could turn into 300, and your project’s funding might be cut. Or you might spend 90 days delivering something only to have it fall flat in the marketplace—or worse, realize that no one knows you’ve delivered a product at all.
Yes, there are lots of potholes on the glorious road to delivering innovation. With multiyear digital transformation projects well into their second or third year at many medium and large enterprises, there is now a lot of nervousness in the technology, business, and design corridors that go straight up to 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 organizational missteps—and those missteps are really costly. Even though enterprises have allocated millions of dollars to these transformation efforts, it’s still proven really difficult to align their business outcomes with their technology spends. Simply throwing more money at problems never works, yet in the enterprise-software world, that is commonly the tried-and-failed remediation method.
While the devil is surely in the details, it seems that the delivery of enterprise software always takes way too long to provide the value we seek. All too often, agile methods turn into waterfallesque quagmires that teams never seem to be able to transcend. DevOps ambitions die when they become the victims of antiquated testing approaches. Or the development of innovative ideas grinds to a halt in the face of conflicts between competing business and IT (Information Technology) groups within an organization.
Another tried-and-true method within any enterprise organization is tinkering. Often, if a methodology or practice fails to get the desired results, people say it’s too heavy and start tinkering. Often the folks who do this tinkering are not wrong. But the typical result is that you end up having a lot of things prepended with the word Lean or agile. These efforts borrow heavily from Lean manufacturing practices, so their spirit is certainly in the right place.
Successful enterprises look at their processes and become laser focused on what needs to change to get the desired outcomes. So Lean Digital Transformation is now a thing, involving the application of 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?
The delivery of innovations is always a struggle—regardless of whether we attach the word Lean to it—mainly because teams focus on the wrong things. Requirements definition is at the center of that circle of wrongness. Even in an agile design, development, and delivery world, the focus on product requirements often gets in the way of delivering. It’s a terrible thing to see a seasoned, talented team focusing on getting the requirements right when they really don’t have a clue about what their customers truly need or want.
In this situation, product teams never achieve a shared understanding of their true business outcomes—outcomes that deliver real value to their customers as well as to the business. When teams fail to align on important business outcomes, what they deliver cannot move the ball forward with regard to innovation. There are three specific ways in which product teams get caught up in the death spiral of requirements gathering:
They focus on delivering journeys that are either too long or of little tangible value to achieving a business outcome.
They underestimate—or overestimate—the data necessary to achieve the desired outcome. Either can create delays in the delivery of a product or service.
They never truly understand the personas that represent a product’s users. Many organizations pay lip service to building pretty, well-formatted personas and feel good about having done their research. However, in reality, they’ve never really known the consumers of their innovative ideas because the personas they’ve developed rely too heavily on the inputs of business and technical folks—whose track record demonstrates that they’ve never really known their customers.
In enterprise-software development organizations, there is also an institutional aversion to doing small things quickly, learning from what works, and pivoting constantly. In essence, this is an aversion to really understanding how to deliver innovation in an agile fashion.
Of course, in the enterprise world, innovation is difficult to achieve. Most enterprises are simply not set up to realize innovations. The sheer number of people who have to sign off, get involved, and have their say can kill innovation in a heartbeat. Many working within enterprises actually see innovation as a threat. Something for people to get excited about superficially, but never deeply permeating the organization’s cultural DNA. This is one reason so many folks in enterprise organizations leave to join smaller organizations and cultures where they can see their ideas come to fruition.
Someone said that every great idea fails at least three times before it succeeds. In this hyper, gotta-have-it-now world we live in, a lot of people feel they don’t have the time to allow for that. However, in a truly innovative, agile-development world, being able to learn fast and keep iterating is what is really necessary.
An Innovation Framework That Works
To really deliver on innovation, we need to stop focusing on the requirements-definition process and leverage design-focused, agile methods that enable iterative delivery. We need to take the time to learn what works and follow a model that leverages fast delivery and learning from our customers’ experiences.
This requires being hyper-focused on delivering small journeys that provide value, with just the right amount of data to support each journey, and the interactions that are necessary to support personas we truly understand. From a process perspective, we need to leverage three things:
Truly agile or Lean development methodologies
Low-code application-development platforms
Let’s look at each of these in greater detail.
While design thinking does not really need an introduction on UXmatters, I’ll provide just a high-level overview.
Design thinking is a problem-solving process that combines creative and analytical thinking. In the digital-transformation arena, we often use design-thinking techniques to answer this question: “What problem are we really trying to solve here?” Design thinking helps us to learn how to drive business transformation and understand the business outcomes we want to achieve. Of course, design thinking is now immensely popular and is rapidly becoming the backbone of innovation in a lot of business arenas.
Agile or Lean Development Methodologies
Too often, the software that enterprises choose to implement an innovative vision is simply the wrong software. They might choose it for legacy, political, or just-plain-silly reasons, but it soon becomes abundantly clear that it’s the wrong software because people have to read a book to understand how to implement it. Then, even after reading that book, it’s still necessary to hire an army of people to move in with them for nine months just to get a log-in screen and a couple of forms people rarely use.
But enterprise software has come a long way, and there are now many better options out there. The trick is to acquire the software that best aligns with achieving the business outcomes you just spent all that cool, design-thinking time articulating.
Low-Code Application-Development Platforms
For those who are unfamiliar with low-code application-development platforms, they’re pretty much what they sound like. These platforms require far less coding and, instead, let teams configure applications using visual-development tools that include everything from widgets to checkboxes, instant connectors, and out-of-the-box templates. The best of these tools are coupled with robust design systems that ensure you never sacrifice the latest design standards.
Plus, low-code application-development platforms empower business users and foster a closer relationship between IT and the business. Teams can produce results faster because they have the right 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 because it provides rapid-prototyping capabilities within your target technology. Thus, its use enables teams to drive innovation. Design is no longer about creating pretty pictures or building high-fidelity prototypes. It’s actually part of developing the product you’ll deliver.
Delivering innovation can be difficult for any enterprise. Achieving success and realizing business value requires planning and coordination. Doing things quickly and iteratively often requires a shift in mindset and culture. Whether you’re trying to achieve digital transformation today or something else entirely tomorrow, ensuring that your organization is outcome focused will be the key differentiator in your ability to deliver the results your customers actually need.
At Pegasystems, Baruch helps global clients develop new ways of streamlining their operations, improving their customer experience, and creating real transformations—digital or otherwise. Previously, during his 12 years at Pegasystems, Baruch led their global User Experience team and served as the principal end-user advocate for the Pegasystems Services organization in their delivery of user-interface design and user experience to customers and partners. He has led and participated in successful efforts to improve user experience across various industries. Baruch earned his Bachelor of Arts in Professional and Technical Writing and Philosophy at the University of Hartford and his Master’s of Science in Human Factors in Information Design from Bentley University’s McCallum Graduate School of Business. Read More