Is our product innovation grounded in insight? (Q&A)

[Bryan]

Today we’re digging into @Jake_Johnson’s article, How to design innovative products. His core argument is that innovation comes from a deep understanding of customers and a clear connection to business goals.

Jake and I have worked together for over a decade. We’ve made decisions together, learned what actually works, and built trust through business outcomes. I feel we both have a strong focus on doing quality work, not just shipping ideas. So I’m excited to chat.

We’ve seen firsthand in projects how teams struggle when they design from assumptions, copy competitors, or try to keep polishing what already exists. It’s when teams look for the non-obvious customer needs and align them with strategy that design really shines. In my experience, that is where great products and design impact come from.

He calls out that innovation happens at the intersection of two things:

• Clear customer insights
• Alignment with business goals

When teams focus on only one side, things break. Customer ideas get lost when strategy is ignored. Strategy falls flat when it is not grounded in real user needs.

Your Ally case study example is a strong example of how this balance actually works in practice, and it reflects what I’ve seen in my own work with customers.

Let’s jump into the discussion

This challenge feels especially relevant right now. I see product and design leaders needing to slow down and look hard at their roadmaps, then ask where ideas are really coming from. Are they grounded in customer insight, or shaped by habit, competitors, and internal comfort?

Here’s the question I want to open up. I see a growing divide between problem discovery and production. AI creates more room to learn from customers, but it also pulls teams into constant build mode because making things is easier than ever.

We have removed many constraints of building things, but do you feel the pull may be moving in the wrong direction?

Let’s dig into product innovation with Jake Johnson. If you have questions, jump into the discussion.

[Bryan]

@Bryan

Here’s the question I want to open up. I see a growing divide between problem discovery and production. AI creates more room to learn from customers, but it also pulls teams into constant build mode because making things is easier than ever.

We have removed many constraints of building things, but do you feel the pull may be moving in the wrong direction?

Great to have you with us @Jake_Johnson. Looking forward to this discussion! Are you seeing signs that we are still grounding what we build in real customer insight, or are we letting ease of execution drive the work?

[Jake_Johnson]

Hi @Bryan ! Thanks for having me and excited to chat with folks on this important topic. I’m seeing signs of real tension here still. Today’s business environment, coupled with real geopolitical instability, is pushing companies to deliver fast. This coupled with AI efficiency initiatives, has created perhaps what we can call the illusion that you can move super fast and still retain the craft and attention to customer insights needed. What I find is missing is context. As we speak, I’m in a Claude Code training If you use Claude Code, you know how important rich context is for success to move fast. What I see many leaders struggle with is slowing down to provide the rich context needed in order to really move fast in product development. This can often lead to churn in strategy and also struggles in defining the core problems we’re trying to solve for users.

[Bryan]

@Jake_Johnson

created perhaps what we can call the illusion that you can move super fast and still retain the craft and attention to customer insights needed. What I find is missing is context.

Ok, this is great. Let’s be honest… when we talk about context, don’t we really mean lived experience? Or are we suggesting something different by the word context?

[Jake_Johnson]

No, we’re talking about the (hopefully) deep input activities such as research, business strategies, PRDs, etc., as well as market and competitive considerations. These all exist but they are not as often distilled in ways that are actionable, reference-able, and as influential to the day-to-day work as they should be.

[Bryan]

@Jake_Johnson

No, we’re talking about the (hopefully) deep input activities such as research, business strategies, PRDs, etc., as well as market and competitive considerations. These all exist but they are not as often distilled in ways that are actionable, reference-able, and as influential to the day-to-day work as they should be

Ahhhh, now your talking my language! It’s the goal of Glare, to help leaders collect actionable research and find ways to create more design impact.

In your experience, what pieces of insight collection are often missed, or ignored when companies sprint to get to releases?

[Jake_Johnson]

I’ve seen teams do all the right things in terms of creating artifacts, but where it often falls down is that these become just that, artifacts. They are static documents that set a project in motion but often get lost in the churn of design and development. Start layering in feedback from those further from the center of the project, and soon drift happens. So you start getting hit from a lot of different directions: personal preference, subjective insights, competing strategic priorities, feasibility considerations, etc. It’s cumbersome to keep updating context documentation and really easy for teams to drift into “riffing” vs. methodical approaches.

The specific inputs that get ignored, depends on the company and culture. Business stakeholders can often ignore or try to discredit user insights. Design teams can over index to user insights without consideration to business needs and strategy. It’s not easy and you need courage to have a lot of frank conversations, always challenging each other.

[Bryan]

@Jake_Johnson

Business stakeholders can often ignore or try to discredit user insights. Design teams can over index to user insights without consideration to business needs and strategy. It’s not easy and you need courage to have a lot of frank conversations, always challenging each other.

Yep, fully agree. Here’s a simple and direct question. Does the use of AI inspire product and creative teams to have courage?

[Jake_Johnson]

Yep, fully agree. Here’s a simple and direct question. Does the use of AI inspire product and creative teams to have courage?

Yeah, it certainly can. AI is just a tool. I was thinking about this when reading Dan Hill’s “Dark Matter and Trojan Horses” over the weekend. In it, he talks about MacGuffin’s, which Alfred Hitchcock coined. It’s a device for moving a plot forward that isn’t always really itself have intrinsic importance.

AI in kind of a big MacGuffin. What it does is act as a force that shines a light on what is actually strategically important. Speed is one. But so is different ways of thinking or challenging assumptions. As well as what I already talked about regarding deep context.

With AI, you get what you put into it. The courage comes in architecting models and training agents that have deep context, challenge your assumptions, make the work better in conjunction with partnership with you, while helping you move faster.

Or you can do a one line prompt. Your choice.

[Bryan]

@Jake_Johnson

AI in kind of a big MacGuffin. What it does is act as a force that shines a light on what is actually strategically important. Speed is one. But so is different ways of thinking or challenging assumptions. As well as what I already talked about regarding deep context.

This is a great way to describe what is happening. Love this reference.

Ok, switching back into collecting insights, especially with leaders, many of them really want to de-risk their product development efforts, but I’m afraid they don’t always know the actual costs of time and effort.

How do you position this work inside your organization?

[Jake_Johnson]

@Bryan

Ok, switching back into collecting insights, especially with leaders, many of them really want to de-risk their product development efforts, but I’m afraid they don’t always know the actual costs of time and effort.

How do you position this work inside your organization?

I’m relatively new at McAfee so still working on how we approach this. In prior organizations, I’ve found proof is always in the pudding. Finding ways to do the work and show the benefits always goes best vs. trying to sell through theoretics. So I’ll often just do the work and make sure it’s represented well. As leaders see results, demand grows.

[Bryan]

@Jake_Johnson

Finding ways to do the work and show the benefits always goes best vs. trying to sell through theoretics. So I’ll often just do the work and make sure it’s represented well. As leaders see results, demand grows.

Yes, appetites start to grow with results. It’s how we’re advocating ideas in Glare.

In your playbook, what matters most when you are stepping into a new role and working against entrenched ideas?

[Jake_Johnson]

@Bryan

In your playbook, what things are most important to get started when you are working on entrenched ideas in a new role?

First and foremost, listen and learn. Then, create a stack-ranked list of areas to work on the most. Find and leverage allies. And find ways to put up quick wins.

[Bryan]

@Jake_Johnson

And find ways to put up quick wins.

Yes. Now this is where it gets tricky as a leader. Wins in the short term are outputs, not outcomes? Results are almost impossible. Is this how you see it?

[Jake_Johnson]

@Bryan

Wins in the short term are outputs, not outcomes? Results are almost impossible. Is this how you see it?

Not necessarily. For instance, we have a lot of momentum in leadership around prototype testing with proven frameworks showing reasonable confidence at reaching outcomes. It’s work that is pretty standard but not part of the culture. The quick win is showing that UX can be measurable in ways that executive leadership can consume and understand in terms of how it ties to business objectives.

[Bryan]

@Jake_Johnson

ndard but not part of the culture. The quick win is showing that UX can be measurable in ways that executive leadership can consume and understand in terms of how it ties to business objectives.

Oh, this is great. We’ve found UX metrics are great tools for building confidence with stakeholders.

This has been great @Jake_Johnson. I appreciate your candor and sharing your ideas in the community. Fantastic. We’ll keep the thread open for others to jump into. Thank you.

[EricZ]

@Jake_Johnson

The specific inputs that get ignored, depends on the company and culture. Business stakeholders can often ignore or try to discredit user insights. Design teams can over index to user insights without consideration to business needs and strategy.

Definitely seen this happen. Have you found effective ways of reinforcing or documenting the importance of an insight? There’s a sort of spectrum of weak to strong, as well as common and novel insights that get weighted in subjective ways.

[Jake_Johnson]

@EricZ

Definitely seen this happen. Have you found effective ways of reinforcing or documenting the importance of an insight?

There’s a lot of value in reviewing research and testing findings with leadership and key stakeholders. This allows you to build alignment around what was important vs. maybe not so important. You can get a lot of insights that are interesting but perhaps not relevant to core business strategy otherwise.

From there, incorporating into project documentation and repeating over and over again is really important. As a leader of mine once said, “Repetition doesn’t ruin the prayer.”

If you can create a repository that is tagged and organized well, all the better. This kind of structured data is becoming even more important in the age of AI where we can synthesize quickly the insights needed for a project over a long and deep data set, but only if it’s organized well.

[MoData]

Love this article @Jake_Johnson! Ally’s work creating more engagement with their savings accounts reminds me of features we built for a client a few years back where we created ‘pockets’ as specific money spending & saving accounts for consumers. We of course used consumer feedback in that project to determine how people think of their financial accounts and therefore how we can provide features that matter.

One thing I sometimes struggle with when building consumer products is that sense of ‘obvious answers’ that are surfaced through the data. Since most of us use similar consumer apps like banking, transportation, social media, etc., some of the insights surfaced can feel like “well duh, I do that thing too”.

I think that’s where the importance of multi-variate testing comes in: use consumer feedback to establish multiple ‘obvious’ directions that a consumer product can take, and then use the same testing approach across each concept to determine which ‘obvious’ feature can make the most impact.

[Jake_Johnson]

@MoData

I think that’s where the importance of multi-variate testing comes in: use consumer feedback to establish multiple ‘obvious’ directions that a consumer product can take, and then use the same testing approach across each concept to determine which ‘obvious’ feature can make the most impact.

All roads lead to Rome, but some are a lot rockier than others