The Product Innovation Challenge

Scott Plewes | November 7, 2016 | 10 Min Read

Innovation does not stem from implementing new technology or design facelift. It is a direct result of clarity around business objectives and customer value.

Over the years, a number of companies have approached Macadamian when they felt pressure to revitalize or modernize their legacy software. The business drivers have ranged from a need to improve user experience and increase engagement to combatting increasing marketplace competition. In some cases, it was even deploying a disruptive new business model such as Software as a Service (SaaS). In every case, the company felt compelled to start a software modernization project in the pursuit of “innovation”.

What stands out the most in working with these companies is that even the most successful organizations sometimes forget “the obvious.” What is the most obvious thing about product innovation? Innovation does not stem from implementing new technology or design facelift. It is a direct result of clarity around business objectives and customer value. These regularly fall by the wayside during product development discussions because of factors like operational costs, timeframe pressures, or even plain old-fashioned human fallibility. The process that guides product innovation should be shaped by business goals, customer needs, and budget. Even though every approach will be unique, there are a few key factors that every company must consider to successfully reinvigorate their product offerings.

Hidden in Plain Sight

The difference between product and business revitalization is subtle. It is easy to lose focus on the business and become fixated on a particular element of the product such as user experience or cool technology. The question that should be addressed is what are the links to business value? For example, companies regularly approach Macadamian because they are convinced their new software has to be “dead easy” to use. These companies struggle in answering the basic question – why. Some believe ease-of-use is tied to increasing market share and strengthening the company brand, while others believe that usability directly influences buyer behavior in the initial stages of the sales cycle. The one common element across all these companies is that they all felt that they had internal alignment on product development objectives – that is until we started asking them questions.

Here are three considerations to think about before launching a product revitalization project:

1. Have Key Conversations Up Front

On occasion, Macadamian has been brought into a software project part way through the development process either because the project is stalling or because there is a concern that the product will not be easy to use. There have been many instances when Macadamian has been invited to a design review only to bear witness to arguments about specific screens, field placement, terminology, how a list should behave, etc.

User Experience (UX) designers often point out, correctly, that users should be involved in helping to figure out whether or not a design is actually usable. It is inefficient to have usability discussions based on the opinions of an internal team. Internal teams often get caught in discussions about factors that make relatively little or no difference in terms of overall value to the customer. For example, have you ever been in a meeting where a significant amount of time was dedicated to the wording of a menu item or the layout of a screen? Consider this: If the particular feature under discussion has very little impact on the end user or the overall value of the product, would the effort and time be better invested in getting the details right where it will make a difference to the customer and your business?

It is normally inadvisable to get users and internal stakeholders involved in every small design decision. Prior to usability discussions, however, it is imperative to have a walkthrough on what users and use cases matter most and why in relation to business goals. In certain instances, there may be business reasons for talking about “edge cases” to reveal the limits of technology or ensure a holistic review for product completeness. However, this does not mean these scenarios deserve the same level of attention as primary use cases or usage scenarios.

Product development teams will typically run into roadblocks when they are not able to implement a design idea, when business requirements are misunderstood, or when the chosen platform is not able to support the functionality the team wants to deliver. The most common characteristic across companies who struggle with prioritizing design or technology decisions is that their focus was on the “how.”

When we asked about how they kicked off their project, we discovered that the focus was on the tactical: project schedule, team makeup, what deliverables were being delivered by whom and to whom. We found with some further investigation that they spent virtually no time on the “why.” A focus on “why” involves asking why the chosen approach is great for customers or the business. Are the priorities aligned for everyone on the team? There was a noticeable absence of formal goals, actions, or success metrics tied to priorities in cases where internal product teams did engage in “why” discussions.

Achieving Internal Stakeholder Alignment

Examples of potential discussion topics to achieve stakeholder alignment on objectives and value:

  1. Product and Business Goals
  2. Customers Goals and Value Proposition
  3. UX goals
  4. Technical Considerations and Implications
  5. Measuring Success
  6. Schedule, Milestones
  7. Users, Usage Scenarios, Product Ecosystem
  8. Roles, Activities, Deliverables, Schedule
  9. Next Steps, Agreements, Actions

2. Course Correct Along The Way

It is easy to gradually lose sight of these priorities when product development projects are based on clearly articulated business objectives. People tend to get caught up in their respective areas of specialty or in what they love to do. It is key that the agreed upon business priorities serve as a constant guide for all the required design and technical decisions throughout the product development lifecycle.

Based on our experience with a broad range of clients, here are a few lessons learned to help keep a focus on business priorities.

A. Clearly Identify Roles & Accountabilities Up Front

Clearly identifying roles and accountabilities up front may seem obvious, but in practice, this tends to be less clearly defined during the initial strategic roadmap planning. There are many reasons for this lack of clarity including situations where a new function has been recently introduced into the company, or where UX consultants have been brought in to do the product design.

For example, UX designers may think they have the role and responsibility for deciding the UX design direction, but the product manager or even the marketing team may also have the same opinion. The problem is that everybody has a different idea and perspective on what is UX design. Some perceive it to be visual design, user interactions, standards, or workflow, while others see it as user requirements.

No matter who ends up with final accountability, everyone should understand who is responsible and accountable for each decision along the way – especially in UX design. UX is the one area where ownership is least clear. The decision-making process becomes inconsistent if accountability is not clear from the start and the inconsistencies will perpetuate and decisions will no longer be linked to or rooted in the stated business priorities.

B. Keep Reminders “Close By”

During the 1992 U.S Presidential campaign, the Democrats used the following phrase over and over again: “It’s the economy, stupid.” This phrase served as an anchor so they would not lose sight of their focus during the course campaign – the economy. It is not always obvious that there is a single business priority that is guiding the revitalization initiative. However, each function probably has a few key aspects related to their job.

We recommend that companies create user personas early on in the product development cycle and keep them as an easy reference guide during the ensuing product design and development reviews. Personas should be used throughout the product development lifecycle to ask the question: “Would that really make sense for this persona?”

Persona development is directly tied to business priorities. There is typically a small subset of users for whom their engagement with the product is critical to the overall business success. Lose sight of these users and you lose sight of the business priorities. User personas can be “included” as the team moves through the re-design and development process. There is no reason this prioritization has to be restricted to design. Developers should be building out the feature list in order of priority. We have seen many projects where the developers have no idea what is the priority. They are focused on getting as much done as quickly as possible. If they have no information or reminders to the contrary, it is completely understandable why they take this development approach. If you start correctly (as indicated above) there is no reason that the stated priorities cannot be carried through and adjusted as necessary throughout the whole design and development cycle.

C. Build In Stakeholder And User Feedback At Different Levels

Software design and development approaches that are heavily reliant on frequent communications (like Agile or lean UX) tend to lend themselves well to course correction throughout. Even if you don’t follow one of these approaches, there is no reason you cannot increase the amount of quick and effective dialogue between stakeholders during the design and development process. There are two additions to constant, small course corrections with internal stakeholders that we have seen to be very effective.

The first is to revisit, midway during the design and development process, the original questions regarding whether or not the project/product is on track to success. How do you know? What has changed? What have you learned? Has this been shared with the whole team? It is hard to undertake this review effectively without a more formal deliberate meeting with a very structured agenda. While this takes a little time away from the hectic project development schedule, the insights and opportunities involved will be worth it. Look back at the agenda you had at the kick-off and revisit where you are relative to your expectations/assumptions. This is a practical way of course correcting in the “big picture” as well as on a tactical level.

The second is to have users and other external stakeholders involved as you go (regardless of how fast and hectic the design and development process is). We have successfully found ways to incorporate this in to the overall schedule without slowing down the product creation process. The resulting insights are invaluable.

3. When You Are Done – You Are Really Just Beginning Again

The last point is to ensure that you need to plan ahead of time to be checking in on the product success metrics that were defined at the onset of the project. Every functional group involved should have had specific goals tied to the overall business success of the product. Success benchmarks should be identified well ahead of time in addition to direct measurements on how to check in on those goals or at least some indicators. Again, the same agenda that started the project (or at least a portion of it) is great for driving what you’ll be measuring in the field when you are nearing release. Ideally, you will have talked about this way ahead of release and you will just be tweaking
the details when you release the product.

In summary, keep a focus on the business and customer goals throughout the design and development process and beyond by taking a little time up front to not only define some of the key goals and their implications but to monitor them throughout. Then, adjust the software-based first and
foremost on the business goals.

Don’t get caught in the trap of believing that design and development decisions are as urgent or as important as they are made out to be. Make it your job to have the organization systematically perform a business goal alignment throughout design and development.

Get Email Updates

Get updates and be the first to know when we publish new blog posts, whitepapers, guides, webinars and more!

Suggested Stories

Applications of Voice Assistants in Healthcare

Discover how organizations across the continuum of care can leverage the growing consumer demand for voice-enabled devices to achieve an extensive list of objectives from increased patient engagement to improved outcomes and lowered care costs.

Read More

Structuring Multidisciplinary Software Teams

5 strategies we've learned from working with the biggest names in software for structuring multidisciplinary software teams to get amazing software out the door fast.

Read More

Guide to Creating Engaging Digital Health Software

This guide shares our knowledge and insights from years of designing and developing software for the healthcare space. Focusing on your user, choosing the right technology, and the regulatory environment you face will play a critical role in the success of your application.

Read More