# AI Product Strategy: The Sense Shape Steer Framework

**Podcast:** Product Momentum Podcast
**Published:** 2026-03-03

## Transcript

We're a little contracted to to talk about AI these days.
It seems like that is always a topic that pops up.
We actually make a joke normally about hey, we have to bring this up once per podcast.
But I think it's gonna be a little bit of our focus today.
But I want to know from you, based on where we are now with the technology with new workflows, what is this new intersection of product in UX and what are maybe what do you what are your what's your take on the future of those roles?
Well, I have to be honest, um Sean, that the boundaries are actually blurring um for sure.
And it's less about who does what and more about really teams coming together and figuring it out in the sense what needs to be done and with that what needs to be done often irrespective of the role, really, be it the researcher, be it the designer, be it the product manager, the conversation often needs to start from what are we solving and why.
So would you agree then that you know in this world where it's so easy to have an AI tool come up with a pretty high fidelity prototype that like we really need designers to be thinking about like, hey, what's actually gonna delight users?
Yes, more than ever, um, actually, Daniel.
Only the challenge is that because building has become so fast so easy, um, I actually find researchers and designers struggle in terms of simply keeping up.
And that's the reality.
Research, there was less patience um in as is in the industry for discovery for the research.
And now that we can actually act on any sort of insight or build something so path, that tolerance level has gone um even further down.
Sean, we just had a great conversation with Bancy Maida.
She's developed a framework for analyzing how to use AI to solve product and design problems.
What are your takeaways?
The big thing for me, why this episode is important for everybody to listen to is we're all looking for frameworks and different ways to solve problems when we think about how can we incorporate AI into our products.
And Bonsi's got a framework for that.
So regardless of whether exactly speaks to the situation that your product is in, it's a new way to think about this specific problem space.
And there's a lot of different takeaways just for product management and kind of like the future of working with our stakeholders in general.
Love it.
Let's have a lesson.
Joining us on the pod today is Bancy Maida, the founder and CEO of Coro UX Design, an enterprise healthcare UX agency supporting some of the US's largest healthcare technology companies.
Her recent UX framework for AI is called Sense Shaped Steer, which went viral with over 7,200 product managers and designers downloading in the first two weeks of release.
I checked it out, it's pretty awesome.
She's drawn to the elegance of a beautiful simple interface and is endlessly curious about AI and the future of human-computer interaction, which I think is true for Sean and I as well.
Welcome to the pod.
Thank you.
Thanks, Daniel.
Yeah, very nice to be here.
Uh uh, nice to meet you, Sean.
Yeah.
It's we're excited to have you because we are framework nerds, so we're pretty excited.
Anything that we can take and apply that day, like that's that's that's always a huge win for us.
I want to start though with something that Dan kind of alluded to.
We're a little contracted to to talk about AI these days.
It seems like that is always a topic that pops up.
We actually make a joke normally about hey, we have to bring this up once per podcast.
But I think it's gonna be a little bit of our focus today.
But I want to know from you, based on where we are now with the technology with new workflows, what is this new intersection of product and UX?
What's your take on the future of those roles?
Well, I have to be honest, um, Sean, that the boundaries are actually blurring, um for sure.
And it's less about who does what and more about really teams coming together and figuring it out in the sense what needs to be done and with that what needs to be done often, irrespective of the role, really, be it the researcher, be it the designer, be it the product manager.
The conversation often needs to start from what are we solving and why?
Like how does it help anyone?
Um, and then from there, really uh move forward.
So I think that has not changed.
If at all, it has become actually more important than ever.
Um, especially where creating a prototype or even a quick experimentation in this, I have actually seen that that I I was part of actually a stand-up today.
It's uh what we call it like one person stand-up, where um every single day we identify that these are the enhancements or improvements we are going to make.
And um literally next day the code is checked in.
So that's the speed in terms of how fast you can really go from quickly discussing idea to actually having uh the product uh uh the code that actually can be shipped, shipped.
So really what's important here is to one consistent consistency, two, to really keep our eyes on who are we solving for, and uh three, really raising the bar as we do it, because I think creating average mediocre products and solutions has become easier and faster than ever.
I like that the focus on is on what needs to be done, right?
Uh, what problem are we solving?
I think we kind of find ourselves circling back to that.
We just had Teresa Torres on.
She talked about how we've done so well working discovery into our product processes, and now that we can ship the speed of light, we've kind of forgotten that we actually need to check back and make sure that we are actually delivering something that people want.
I think one thing that I want to clarify is from a roles perspective, I know I know you said that the focus needs to be on what needs to be done.
Do you see like some sort of future hybrid role where the actual the expectation is that you're able to do that you're that your skill set is rounded enough where you can actually do both parts of the job, or do you think that there'll still be distinct disciplines moving forward?
I say that there is some merit as some some ground where anyone can do the basic prototyping, in the sense, really clear using Claude, using using Claude Core.
Um, you create, you at least go from idea to having something that you can tow and then have a conversation around that.
I think is becoming more table sticks than you would like.
Uh, in terms of really polished craft, where you're thinking on the edges, you're really pushing the envelope in terms of solving this problem creatively, um, and better than the most.
That's where, yes, the craft is still required, irrespective of what tool that you require, uh, that that you use.
So for for designers, really, hence it's less about really just being pixel perfect or the speed in terms of oh, this is how fast I can create screens and mockups, and more about really re and that's that's why I precisely use that word raising the bar, because that's the conversation I find myself having again and again with the with my own team as well as the client teams.
It's easier than ever to turn screens.
You can have full workflow, and the way AI creates stuff, it is designed to be right, right?
It's designed to be that average mean, which means you will never look at it and think that, oh my god, this is so bad, or no, this doesn't work.
You will mostly actually nod your head and say that, okay, yeah, that makes sense.
That that works.
And that's really the trap.
In the sense, if you if you use that as your starting point, before you realize that quality really diminishes in the sense if everyone is creating similar solutions, it is really your average middle as opposed to really thinking out of the box, pushing the end well up.
And um, that's where I feel that designers specifically really need to raise the bar in terms of what how we solve the problems and uh how we even if you are using AI, how we really push the limits.
I love where you said talking about diminishing quality.
So somebody came to me.
We are always evaluating new AI tools.
Somebody came to me like, check this one out, check this model out.
Look, I asked it to create this user story, and look, I've got seven pages of content.
My first question was, is it good?
Right?
Yep.
All we knew was that there was a lot of it, right?
Quality is not volume.
So I love that answer.
Thanks.
Yeah, you can see you think you said something really interesting to me that goes with something I was actually reading last night around the trap, right?
And you said how right AI solutions kind of drive to the middle, right?
They're driving to the mean.
Which it's it seems like, right?
That there's a trap there where you get this prototype, you say, This is awesome, and then your creativity diminishes because now you're looking at a thing and like you you've kind of built in like, oh, this is how it should be.
Um, on the pod, we're big friends of uh Nezri and Shangell and your product delight.
Um so would you agree then that in this world where it's so easy to have an AI tool come up with a pretty high fidelity prototype that like we really need designers to be thinking about like, hey, what's actually gonna delight users?
Yeah, yes, more than ever, um actually, Daniel.
Only the challenge is that because building has become so fast, so easy, I actually find researchers and designers struggle in terms of simply keeping up.
And that's the reality.
Research there was less patience um in is in the industry for discovery for the research.
And now that we can actually act on any sort of insight or make something so fast, that tolerance level has gone um even further down.
Yeah, it's interesting.
So Sean and I were texting before the pod.
Um there's a tweet that came out recently by a guy named Dax Reed, who is a developer working basically for kind of a no-code AI solution.
Uh, we had this quote, you know, your org rarely has good ideas, ideas being expensive to implement was actually helping, right?
Like that was a feature and now we've removed this.
So I'll talk a little bit about your framework, right?
The sense shapes steer model and you know, how your ideas are coming up to kind of make sure that the ideas are actually good before, right?
Before we actually go and build them quickly and find out that they they weren't so good in the market.
Right, right.
Well, I actually you won't believe the framework came out of pa came more out of necessity than really where we say that, oh, we have figured it out and this is the way to go.
And why I say that is that I I keep coming across teams and problems and the way we saw and how and everyone seems to be struggling how to how to approach it.
In the sense there are there is a variety of starting points when we think about solving for AI.
And when I say solving for AI, it means really creating either features which are AI-based or reimagining the whole product or creating a brand new product idea, which is AI native product, right?
And both ways, it uh I have seen the struggle in the sense.
Um, oftentimes it will start with some sort of a POC that an engineering uh team or somebody who could prototype and show that we could build something with AI, will build it.
People will get excited that oh wow, we can do it, and that and then the whole conversation starts in terms of retrofitting it.
That okay, now what problem it solves, how well it solves.
I I was actually surprised that how early in this stage I was already having conversations where somebody would come to me in terms of a prospect or a client or the team, and they would say that we actually build this and it works.
The problem is that either there is no adoption or people are not able to figure out.
Because there is a mental model shift, right?
There is a complete paradigm shift.
To Sean.
Your the point that you made earlier, where it's seven-page of document, it's a real thing with AI, generating more content is easier than ever before.
And I mean, we work in healthcare.
So AI scribe and visit notes, uh, you uh translating it in terms of the soap notes, that's a very, very common scenario nowadays, right?
And it's actually well adopted as well.
The problem is that it's when when we think that yes, AI can actually listen to the whole conversation ambient listening, right?
And then create the SOAP node or visit note, the user experience in the quality of the note itself and in the nuance, right?
How well it captured versus not captured, and it doesn't end there.
It is there is a there is a serious conversation in the sense that what we talked about earlier, that if if the answer is your average mean, even doctors will nod their head and they say that, yeah, this looks good, as opposed to being vigilant, which they need to be, and on the other end, with more content being generated, is it really reducing the work for the providers?
Or they have to now go through it line by line because ultimately it's still their license on the line, because that's our way of really offloading the liability to human.
Um, in other words, also human and loop.
You can look at it both ways.
So, so I mean, and these are the points where you really want to question, right?
That what is the user experience?
Is this actually helping the user?
Do users perceive that they're that this feature or this capability is actually going to improve their life.
And that requires going deeper, going looking under the hood in terms of those responses itself and what will give accurate uh response versus not accurate, right?
Where it will elucidate, where it will actually create unnecessary amount or versions of uh content as opposed to really sticking to the point, so on and so forth.
So, yes, that was more out of the necessity that we need some sort of a structure in terms of how do we approach uh different kinds of AI problems um that come our way.
Yeah, I definitely want my doctor to check the notes and make sure she's prescribing me like 500 milligrams instead of 500 grams of amoxicillin for an ear infection, right?
A wheelbarrowful pills.
Yes.
Can you walk us through kind of step by step through your framework through each through each of the three steps?
Walk us through that and talk to us about what what questions we're answering, why it's important.
Maybe some tips on like how to execute the step.
Could be a longer answer, but I'm really excited to hear about your framework.
Of course, of course.
So um, the framework is actually, yes, as we said, divided into three parts, what we call sense, shape, and steer.
So sense is where you are really creating that sense of what is possible, what is worth solving, and uh before you actually go about saying that okay, we are going to solve it, and these are the ways uh in which we can solve it, right?
Which is really the shape part of it.
Now, if we talk about the sense part, and if I have to really explain it very simply, it is really the intersection of what is the user needs, what insights we have in terms of the challenges or the opportunities that are present.
So insights are still the bedrock of the scent in terms of where that's our starting point.
But we don't stop there, unlike how we used to do before or how we would for non-AI product, right?
With their discovery, and then you directly start with the ideation.
But here we say that okay, these are the insights or these are the problems to be solved.
Now let's look at the AI side of things in terms of what are the possibilities and um what what AI can do for us.
And where we see the intersection, that's the sweet spot.
And how do we make sure that there is some scaffolding or structure around it in terms of how do we really evaluate what are the AI opportunities, right?
That's where things get interesting, actually.
That's that was really the purpose behind creating the framework to create that scaffolding.
So it allows you to think step by step.
Like for example, one thing that we really think about is that one, what do we think that AI has access to versus not have access to?
And now with AI advancing with agentic AI, with NCP, all of that, you actually really want to the want to get to the depth of it in terms of what data set or ground tooth do we have growth that we have that would actually be used to train the AI.
That's one, right?
Another thing that we really think about is what is the experience mode.
In the sense, again, I see when it comes to AI ideas, the conversation often starts with, oh, we need a co-pilot.
Or, oh, we are going to build agents.
And we can build this kind of an agent in this application that can do this, this, this, right?
What we want to do is really start with that what is the opportunity, AI opportunity and user opportunity, and then really say that okay, if we say uh AI, what experience mode it is, right?
Is it going to be ambient listening?
Is it going to be generative AI?
Is it going to be agentic AI?
And agent AI also have multiple layers, right?
Um, it is it is not really just one task oriented.
So, how sophisticated we are talking about?
Is it really one individual microagent?
Which is also fine.
Like, we have also built uh experiences for very simple agent, where it all it would do is really when you are creating uh let's say a new workspace, all it would do is just help you with documentation in terms of what are you building and hence what should be the dick description, as well as on the other end, really the whole orchestration, right?
And both needs clarity in terms of what kind of AI uh mode it's going to be, and then what role AI will play in this.
In the sense, yes, and this is where we are really building the hypothesis and hence the sense, right?
This is where we're really building the hypothesis that okay, we think that AI can do this, this, this.
And that's how we actually build further understanding in terms of we are expecting that AI can help in terms of taking the notes and then creating follow-up tasks.
AI can really, for example, understand that who this task would be best assigned to, right?
So recommendation that, oh, these are the follow-up tasks uh for like let's say, for example, a provider, and this is who it should be assigned to and how it's going to do that.
And third and very important thing is where we also talk about the risk and uh guard rate.
Um, and this is where we actually talk about that what could go wrong if AI makes a mistake.
Because this is where we already start thinking about that how much honors we want to place on AI in terms of it being really, really right, versus how much autonomy that we want to really keep in terms of with the user, right?
So all of these steps that we go through that allows us to really wrap, and this is not for the designers alone.
The beauty and the right way of approaching this is that this is a combined conversation between engineering product and design, where they are actually going through this together and trying to figure out.
Right, so a lot a lot to unpack there.
Um, so it seems like right, the sense framework is very much your problem space identification, right?
Yeah, identify, you know, an opportunity either from your product design side and determine okay, where might AI fit into this.
So I'm curious, you're right.
You're kind of talking about, you know, the model were hey, what are the risks of using AI and like what's acceptable?
Um, is your framework kind of have a go no go for using AI to solve that problem?
It is contextual.
Um, it's a framework-wise, yes, we should agree on the success criteria, and that success criteria is where we have this discussion.
For example, we know that how you said, right, that uh when your doctor is actually going uh creating the ITM-rated nodes and there is prescription, you want them to really look at it, right?
So depending on where we are applying AI, how high stake it is, how easy or hard it is to revert or reverse that step or action, all of that really depends in terms of what are the critical success factors and how accurate we want the AI to be.
And it goes both ways.
One is really we keep human in the loop, but there is also a cost in terms of whether that human in the loop will lean in in terms of untrusting AI versus not.
And I'll I'll give you an example.
Um, again, in healthcare space, there is something called RCM, so the revenue cycle management, which is where after the visit and every everything, how the billiard billers and coders will kind of prepare and submit for the claim and how they'll get payment, right?
So this is the conversation that we need to have in the beginning to really say that yes, we want actually 80 to 90% of recommendations to be accepted by users for this product to be successful, right?
Or for example, in terms of follow-up or even prescription, we would probably need it to be 99% accurate for it to for users to really feel that yes, I can actually trust and I want to lean in as opposed to every time being skeptical and unsure that is it the full list?
Am I missing something?
Do I really need to go through everything and held the sense of actually my my word has increased as opposed to decreased?
So having going through this exercise really allows to surface these kind of problems early on, um, and then building for that.
Uh, because there are ways, right?
In terms of how you can circumvent all of these uh situations as long as there is a conversation around it that we surface it.
Awesome.
Take us through the shape step.
What are the problems that we're solving and give us some execution tips?
Right.
So towards the end of sense, what you want to walk away with is some sort of an opportunity statement, and I call it opportunity statement as opposed to the traditional uh discovery where you will have a problem statement.
Because oftentimes it's it's an approach AI opportunity that we are talking about, right?
We walk in with that, and in shape, um, there are a few things which are really, really important to start with.
Uh, first and foremost, because we are talking about AI-based features and experiences, there may or may not be interface in mod.
And that's why the emphasis is that we don't start with really Figma, because when we start with Figma, we tend to think interfaces.
What we really emphasize on is that based on what we think is the opportunity uh statement and what we have seen in terms of the kind of uh UX challenge that are UX problem that we are trying to solve, let's think from user's perspective and create a storyboard.
And that storyboard again has a certain structure where what we are go doing is literally the storyboard style, frame by frame, we are thinking from users' perspective and saying that at every frame what the user is trying to do uh as part of the journey, the problem that we are trying to accomplish, right?
Uh, what are what is their goal and what is the action?
Um, at one on one swim lane, this is what we are talking about, and on another swim lane, what we are talking about is that so what is the context?
Why are they trying to do it?
And um, what is the design decision in the sense should AI interfere here?
Should AI here be more of silent, let user do it, versus this is where AI can actually nudge, or this is where actually AI can already generate some sort of an insight and give user that boost depending on what they are trying to accomplish, right?
Okay.
I like where you're good with model selection and token costs there.
I think the general population of AI users are starting to become more conscious of that.
Um, use the models for specific tasks and then just kind of like what the cost of tokens actually is.
Yeah.
Let's get to let's get the steer.
Tell us about okay.
We have our journey map, we have our AI touch point map.
What's the steer step?
So steer step is an implementation.
Steer comes once you have built something and you launched.
However, it is it is worth going through it while you are doing this exercise in terms of at least having some sense of definition uh around steer part because tier is where you really define your AI evals, is one very important part of uh steer.
And I have seen actually product making it or breaking it in terms of uh make or break kind of a situation for the products in terms of if they have got their AI events right or not.
It's one thing to in hypothesis saying that this will work and this is the kind of accuracy level we want to uh achieve in isolated use case, and it's completely different thing when you actually try to build sophisticated, let's say agentic AI layer, right?
Where there are there's multiple configurations for the agents and in terms of the uh the prompts.
So um there was this one solution or product that we were building, which was about the uh the compliance in the sense that for every call that was made, how compliant it is it was on certain predefined guidelines, and um there it had to be accurate.
It cannot be where AI actually goes through the whole call conversation and then comes up with evaluation and says that, and and then we write about let's say 80% of things, but not write about 20% because that means a human will still have to go through the whole thing to determine how accurate it was, right?
And at the same time, it was it was not a simple orchestration in the sense where it's not a simple yes or no, it will depend on what is the protocol it is testing against, right?
Um, how sophisticated it is, in which which certain scenarios it will fake, and that's the level we want to get to in steer in terms of saying that what will be the AI evaluate criteria, how are we going to test it?
Because it's not the normal, it's not a QA in isolation who can do the AI above who sometimes needs subject matter expert, right?
To really say that this was the right medication that was detected or not, right?
Or this was the right kind of a follow-up and the allocation that was suggested by AI or not.
That's not something that a designer or a developer or even QA can do.
Maybe they can do it for certain set number of data set use cases, but um when we really want to pressure test, stress test, we want a subject matter expert alongside, right?
So this is the conversation that we have where actually where we actually talk about different uh metrics that we are going to judge the success of the uh the whole AI-based opportunity that we are exploring.
So one is really accuracy, and you don't always need 100% accuracy, it's subjective, right?
But we really need to understand that what is that there is a fallback option, there is a reversibility, or there is human in the loop, this much is acceptable versus below this level is not acceptable for XYZ reason.
The important thing is that we actually are able to test it and prove it that it actually helps them, right?
Trust metrics to say that what will uh what what will make users adopt is versus not adopt it, and how are we going to define that?
Like, how would we say that yes, this is the adoption, it is acceptable versus not, and what could actually affect it?
So, again, defining this early on allows uh teams to be vigilant about it, already prepare for it as uh we are as we build the AI solution and we are ready to deploy, because a lot of AI experiments uh remain experiments and they don't get actually deployed purely because the thoroughness is missing.
Okay.
So I the thing that I like about Sense Shapes here is that while it is designed, while the framework was designed out of necessity for understanding the best way to build AI AI products.
I think that there's a lot about just building products in general and the way that you need to work with teams and subject matter experts throughout your entire process in order to ship something relevant, and then how you learn once you have once you have at least your first draft of your finished product.
That's awesome.
I have some takeaways from I have some takeaways from everything you've you've given us today.
My first one is the one that I really liked about uh it's less about who needs to do what and more about what needs to be done.
I really like that.
I really like that take.
Part of expertise is recognizing diminishing quality.
We've talked about, you know, how people present us with something that's not ready but they think that it looks cool, right?
And we're able to recognize that it's a poor quality because of our background because of our expertise.
I really like the Shenz Sense Shape Steer Framework.
And then also something that you said that has resonated with a conversation that I had with a client last week was rethinking when an interface is appropriate.
The conver I can't get too deep into what we talked about, but ultimately it came down to why do we actually force a person to log in to do this task?
And those because it's the only way to get access today, right?
And in the future, we might want to have, you know, whether through MCP or through other some new authorization protocol, right?
We might just want to say, we might just want to ask AI to do something, an AI model to do something that we have access to that we've authorized to go take action on behalf of ourselves in another system that requires authentication.
Right.
So the interface may the in interface design is going to be something that's gonna be really interesting to watch in the future.
Yes.
Thank you so much for being here today.
We love hearing about new frameworks and models because we like to be able to take away something we can tactically use, you know, today, this week, something that we can share with our teams to get people thinking differently and changing their way of working.
It's been at it has been absolutely a pleasure, Sean.
I I I personally feel that I know teams are really struggling and people are really trying to wrap their head around it.
So if I if this framework can help teams in terms of making sense out of it, still uh and still move at the pace that they are required to move in this time and era.
Um, I mean, I think that's that's the biggest um gratification for me.
What's the best pay to what's the best way for people to reach out and see what you are what you're working on now?
I would say LinkedIn message uh would be would be the best way.
All right.
Well, I hope hopefully you're ready for a flood of ink of LinkedIn messages.
Thank you so much for being here with us with us today.
Yeah.
Thanks for joining us in.
Thank you.
Thanks.
Thanks, Daniel.
Thanks, Sean.