Maximizing your team’s ROI in product innovation

Supporting a culture of experimentation through user research

Pathway to Innovation

I really like the definition of innovation I read in this IdeaScale blog post. “Innovation is defined as the process of bringing about new ideas, methods, products, services, or solutions that have a significant positive impact and value.” It’s broad in that it doesn’t dictate the hows and focuses on bringing significant positive impact and value. After all, that is the outcome we want from our efforts toward innovation but ask your customers and you won’t likely hear “Add something innovative!” as their answer. I’ve found customer feedback is frequently centered on solving problems. Leadership feedback is where “innovation” will come up and may often include the adjectives “shiny” and “new”. Luckily, user research can help answer the questions that give both sides what they want.

If your organization is truly innovating in its field, they have embraced user research as more than a “nice to have” if the budget allows. Design-mature organizations know true innovation that drives customer satisfaction isn’t always shiny or new but is crucial for experimenting the way forward in its industry. No matter your industry, much of what makes user research a cornerstone of innovation will be similar. I’ll highlight five of the areas I’ve found user research to be most helpful but really, it’s everything.

I Know You (Pts. I-III)

Foundational user research is the baseline on which product teams build everything. A big part of this is knowing your customers by the data collected and the behaviors they demonstrate while using your products. Focus groups and individual customer interviews are a great way to expand on this quantitative analytical data with qualitative feedback. Combining both via live data that feeds into your personas creates living user personas that evolve with your customers' behavioral changes.

This isn’t user personas that include cute anecdotes about where else they may shop or what kind of pets they may have. Unless the persona information included is data-driven and relevant to your industry, it’s not helping anyone do effective work to drive revenue and customer satisfaction increases. Skip the fluff in favor of knowing who you’re building for.

And to that question, the answer is everyone. It’s always everyone. The customer life cycle moves from new customer to loyal customer quickly. Rarely can teams afford to build one-off experiences that exist outside of this broader cycle. Design and build holistically to include new and expert-level users, desktop and mobile users, standard access users and those using assistive technology.

What’s Going On

Knowing what to build means knowing when to build new versus working to enhance existing features. It can sometimes be difficult to determine which way to go even when we know our customer. We know whatever we build needs to be accessible, easy to use, and consistent with our brand style and voice but is that innovation? Well, yes, it can be. I often hear product teams say “But we’re already doing those things!” and that’s great. Or I should say, it’s a great start, but nothing in product development is one-and-done. Remember the inclusion of “solutions” in our definition of innovation? There’s always more than one way to solve a problem. Research-driven experimentation means not settling for good enough for very long. If your team has dedicated researchers, is focusing on systems design, and is developing with a componentized framework in place, you’ve cut busy work to a minimum. You’re in the perfect place to maximize your innovation investment.

Maybe you thought your card-sorting research had resulted in the perfect information architecture when it was first conducted, but what have you added since then? Has the placement of new features caused customers to implement workarounds to reach their goals? Could you bring this functionality forward to ease some friction they may not be aware of?

Are teams with a dedicated payment endpoint each using their own components for customer and payment information? Could these be consolidated into one dynamic component suitable for every instance?

Iterating on existing solutions can often achieve the biggest wins with the smallest level of effort. Sure, building a shiny, new bridge is exciting, but moving whatever has been stranded on the other side of the river may be faster and easier.

How Soon Is Now?

You can’t simply ask a customer “When would you like to see this amazing new feature you’ve described?” If you’re talking about solving a customer pain point, the answer will usually be “yesterday”. So how can user research answer the “when” question for product solutions? When you take their feedback and your designs back to the drawing board you’ll probably come up with at least a couple of ways to move forward and address the issues that have surfaced. Do this with enough feedback and you could soon have a list of features that test well and are developmentally feasible. Now, take this list to those same users and conduct some ranked sorting exercises. Your customers may be willing to wait on certain features if they can get the biggest headaches eliminated first. In my experience, they’re more than happy to help your team prioritize your backlog of features.

Of course, the level of effort and available resources are what usually determine feature list prioritization but in a toss-up, solving your customers’ biggest challenges should always be the tie-breaker.

Where Do We Go From Here?

I’m a big feature parity advocate. Thanks to being part of hundreds of user studies throughout my career, I know the weight of “Why can’t I do X on mobile (or desktop)?” and its cost on customer satisfaction. As product teams, we know the reasons behind the answers to that question are often technical and complex.

The main reason I’ve heard for feature inequality across digital experiences is due to the codebase. For many brick-and-mortar companies who were early web adopters, their systems can be full of spaghetti code cobbled together over the years and held in place with the digital equivalent of duct tape and bubblegum. Once the need for a mobile app became apparent, they built one from scratch and “did it right” from the start. Now, years later, their app may be suffering from the same fate. Parts of their mobile experience are pulled in from the web cough, sign-in, cough or time has heaped on enough technical debt that starting over can look more feasible than fixing those less-than-delightful aspects of their product.

No matter what reasons are behind a lack of feature parity I’ve learned your customers don’t care about your reasons. They’ll suffer through with your product for as long as they have to but as soon as a better option presents itself, they’ll switch. If your team is unable to work cross-platform, you can still get ahead of this outcome by doing the research and figuring out which experiments provide the best experience on each platform. When you’ve got the data to show your experiment is now a value-driving innovation, product design can collaborate with the product and user research teams to design and test the full experience so it’s ready for development when the parity stars finally align.

I Wonder Why

I don’t advocate for building what customers say they want. Likewise, whatever you think customers want is at best only partway correct. If your team doesn’t understand the whys behind a solution, they won’t be able to see the path forward to iterate it into the realm of innovation.

The power of a strong product team is not only the individual skills each has developed but also how each member sees, thinks, and imagines things differently. Add a dose of robust analytics and user research and your why becomes data-driven and customer-centered with everyone on the same page regarding the problem to be solved. Then your team isn’t thinking “What will we build?” but “What will we test first?” to learn and gather data on what to finally build. More data means less ego, more collaboration, and a common goal. Plus, a common understanding of why you’re doing the work means each team member can keep working it into a more perfect state through iteration and continuous improvement.

This Is How We Do It

Using experimentation and user research it’s possible to cycle from “problem to be solved” through testing and learning, finally arriving at “significant positive impact and value”. But remember that in most cases each step toward the final solution means one or more significant failures. Sometimes things just work and we get to say “Ah, just as I suspected” but it’s harder to know for sure unless the failure of one or more ideas brings you around to the successful one. When failure by even a fraction of a percent translates to millions of dollars in revenue and a possible customer satisfaction rating dive, it’s better to learn what doesn’t work early and from the safety of systems designed for experimentation.

Also, remember that the payoff of successful experimentation and user research will not only cover the budget concerns around the costs of building such a culture but will keep customers happy, drive loyalty, and make brand advocates of your most loyal customers. All this results in revenue increases which is the real ROI leadership wants when they ask for “innovation”.