Everyone. Thanks for joining. We’re going and get started. We’re doing another session of what we call ENO8 answers where we try to pick up certain types of questions or challenges that we frequently see our clients come across and just talk about those and you know, get that information out so others can benefit from it. And like I said, a few minutes ago, while we were just kind of hanging out waiting for people to join highly encourage you to, you know, drop questions in the Q and A window and I’ll kind of keep an eye out for those.
Jena Lee and Jordan from our team will help us keep an eye for that too and then we can address those as we go through this.
So, you know, the topic today, we, we’ve done this one a couple of different times, but we’ve, we’ve gotten feedback and questions about that.
We would revisit this one again and we’re actually gonna try to capture a pretty good recording out of this session so that we can, we can use it that way too just because we, we find that people come across this problem a lot.
So what, what the topic is that we’re gonna talk about today is how to pivot when the product landscape changes during development, a proven formula.
And so this is, we’ll get into this a lot today, but in essence, what this is is you’re in the middle of building your product and something significant changes.
So what is a good sort of methodical way of responding to that type of landscape change?
So, we’re gonna dig into that today before I do just a little bit of quick background on me for those of you that don’t know who I am.
My name is Jeff Francis.
I’m one of the co-founders of ENO8.
We’re a ink 5000 Digital Innovation studio based here in the Dallas Texas area.
Me personally, I’ve, I’ve worked with over 100 startups to design and build and launch their new digital product.
And so I’ve got a lot of thoughts on this topic.
I love talking about this topic.
got a lot of scars from this topic and learnings as a result.
So really excited to do these types of sessions to just talk about that kind of stuff and help other folks that are on that journey.
So let’s dive right in first off what are examples of landscape changes.
So when we talk about how to pivot when the landscape changes, let’s talk about what, what would that maybe look like in reality.
And so we’ve kind of put together some examples here of what kinds of things would constitute landscape changes that as a result can, can create challenges.
So some of those, one of the ones that is most common is, you know, new, new competition, right?
That could be in the form of, we discover that there is a new competitor in our space that we’re going after that we weren’t aware of before.
But it could also mean that we’ve discovered that a existing competitor has done something that might impact what we’re doing, right?
And so competitors can take different forms.
you know, it could be another software company that’s building some kind of a product, but especially like in the mobile space, a competitor that a lot of people don’t think about is a competitor that is also a partner, right?
So a very simple example would be, you know, look at what Apple will frequently do with, with great features that they see in other apps, they’ll take that feature and they’ll incorporate that into an OS update at some point.
And so like a really simple example would be, you know, like I remember in the early days of the app store, there was apps for literally every single feature that, you know, that, that, that wouldn’t even really be a true product to stand alone on but I remember like the flashlight app, I don’t anybody remembers that or not, but there was actually an app that you download from the APP store just to use your, your camera light as a flashlight.
Right.
Good idea.
But, and they, they had a ton of downloads or probably even made money off of that while it lasted.
But Apple said good idea.
We just made that part of the Os and then that product has no value anymore.
So small example, internal leadership changes, this one can happen in small companies but probably is more frequent and larger companies in, in large organizations.
We find that one of the big challenges aligning all of the different stakeholders that all have a different role, different perspective, different priorities and objectives.
And so sometimes a change in internal leadership during product development can drastically change where, what, where you go with that product, especially if they’re really senior position.
So if it’s someone who, for example, is a head head of innovation or they own, you know, digital client experience, right?
And you’re building something that really is significant in that role for your business that could potentially introduce some disruption and change what direction you need to go, regulatory changes.
We hear a lot about that in a variety of different industries, lost valuable team members.
This is another example.
you know, there a lot of times there’s, there’s, there’s turnover in key positions, especially on, you know, product teams.
It’s very competitive for that talent.
They have lots of options and, you know, people leave sometimes and so sometimes having someone that’s key on the team, either if you’re doing the in house, you know, and that person leaves the team or if you work with a partner and someone from their team leaves, that’s something that could change the landscape, economic changes is a really hot one right now because everyone’s looking at what’s going on right now trying to determine is there gonna be a big recession next year or not?
Right.
And so that can definitely change your planning and approach for a product.
And so an example that could be looking at your product road map, right?
And knowing that there’s gonna be additional pressure on being efficient and impactful with how you approach your product road map, right?
Which will kind of dovetail with one of these other ones, unexpected budget cuts, right?
So what I’m seeing a lot and I’m hearing a lot, especially from enterprise clients is that they’re being asked to continue to innovate and push initiatives forward, but they’re having to be asked to do that with fewer people, less resources, less budget, which means you got to be much more calculated on what shots you take and how you approach those shots so that you can maximize your potential for success while reducing the amount of resources required to do that.
And in that respect, I think that’s a lot like how startup companies have to approach product development, which is what I like about this topic is because I think there’s a lot to be said about enterprises approaching digital innovation and launching digital products like they were startups because oftentimes startups have to work on really thin resources and they have to make sure that at every stage of the, the journey they’re validating, they’re meeting objectives before they sort of go to the next step.
And so, I, I think that there that we can bring a lot of that approach to working with enterprises and solve a lot of challenges.
They’re even having today opinions, priorities of key stakeholders change.
This is a big one.
I, I’ll talk a little bit about this sample product that we helped with later on in the presentation.
But I’ve seen where, you know, there’s stakeholders that, that, that may have different functions within the business and along the way their own priorities change or their opinions change.
And so, you know, that can be a landscape change and then changes in technology or feasibility.
This one’s more relevant today than ever because the, the, the pace of technological change is just increasing.
And so sometimes what I’ve seen in several instances is a decision that was made at the beginning of building a product based on feasibility or what technology was available actually changed during the product development time, right?
So we were, we made a decision, we started moving on that decision to build the product.
And then while we’re in that process of developing the product, one of the things changed that led us to that decision.
So what do you do about that when that kind of stuff happens?
Right.
So these are examples, not an all inclusive list, there’s lots of different things that can come up unexpectedly, but this is an example list of some that we see pretty commonly.
And so our approach to that is what we call the pivot, right?
And this is sort of an acronym for the different steps that we’ve created to kind of give a structured approach to.
You’ve identified some kind of a change in the landscape, what do you do about it?
And so this is our strategy for dealing with major changes.
So I hope this helps the P stands for pause.
This scares people a lot of times, but as you may have seen in some of our blogs and other videos, I’m, I’m a, I’m a pretty big fan of when there’s a lot of uncertainty gets introduced.
Sometimes it’s best to pause, assess and move forward.
So what we’re saying here is pause and detach from the turbulence, right?
Sometimes there’s pressure of we’ve got a timeline, we’ve got this team working.
I can’t stop them, you know.
So, but so there’s that, that stress of doing that sometimes.
But, but, but very frequently the right thing to do is pause, make sure you’re not burning your budget and you’re not going down the wrong path that you’re, you’re regrouping with who you need to regroup with a lot of the things that we’re gonna talk about here throughout the, the, the rest of this step.
But, but pausing can be a really good first step.
So pause creates space for thoughtful solutions rather than band aids back up.
And let’s really assess what’s going on, Acknowledge that things aren’t going how you planned.
So I think this one is just being honest with yourself, right?
Like, hey, I’m gonna put my pride to decide, maybe the decision I made potentially is not the right one at this point.
Let me be honest about what’s going on and not sort of committed to a certain path just because that’s the way we’re going.
I think by creating that space to be curious and to explore is something that really, it helps to make sure that you’re making the right decision and, and, and that, and by the way that approach that applies really well, you know, in a situation like this where there’s a landscape change, but also in product design, you know, when you’re trying to envision a solution, a lot of times people jump to the solution right from a problem instead of first sort of opening up exploring the problem before they narrow down into a solution.
So, same kind of concept here.
And number three is just be brutally honest about what is going on if you made a mistake.
And that’s kind of where we’re here.
Just be honest with yourself about that so that you can actually take steps to, to rectify it.
Right.
The other one could be just being honest about, you know, what are the real factors at play here, right?
Be willing to sort of explore everything so that you can really arrive at the best answer.
So P is first step.
next is I identify what has changed.
So this is sort of about clarity, right?
So, actually, you know what, I’m gonna jump back because there’s a really great example that, that we ran into a, I think it would be valuable and before I jump onto the next one.
So one of the best examples I’ve seen of someone doing this was there was a client we worked with several years ago and they made a decision before we started working with them to to use a third party product to basically build this, this, this e-commerce experience for their customers.
And I think that they made the right decision at that point in time.
But the further that they got into the project, the more it become, more, it became obvious or more clear that that product probably wasn’t gonna get them all the way to where they wanted without a great deal of effort.
And, you know, once we started working with them, they brought in someone new to get involved with the project.
And one of the things I thought was, was really interesting about their approach and, and how we work together through it is they were willing to back up and question the entire premise and, and what I, what I, why I think it was really bold in that case was they had made a very significant investment to get them to that point.
But then it was just getting really hard to get it across the finish line.
And the this person was willing to ask the question, are, are we, are we even going to be able to get there using this platform and this product, is this the right direction, right?
Like even being able to question that kind of stuff was kind of risky, right?
And so, I thought that that sort of like intellectual honesty about kind of evaluating the situation, really led them to, to, to be able to find the right path and, and then we were able to, to be a part of that.
So that, that was an example there that I, I wanna make sure I got, I got inserted this next one.
So back to, to the to the next step I identify what has changed, right?
So being really clear about what exactly is it that’s changed so that we can put our finger on it.
And so a couple of tips here, I think that will help is enroll others and assess the situation.
So you’d be surprised what you get when you, when you look for other points of view from different people involved with the effort.
So that could be, developers, could be stakeholders, could be even potential customers.
So enroll others so that you can get better information and then start to hone in on you know, the right answer.
Number two, like, you know, clearly identify the change and issue.
So what’s the obstacle or challenge does this create?
Right.
So why is this a problem?
In other words, so we’ve identified something that’s changed, it’s caught our attention, it might be a concern.
Why, how is that gonna impact us?
What kind of a challenge or risk does that introduce to us?
And then the second one is creating a response to each one of those obstacles.
So one of the things I like to think about is like, OK, something’s changed.
What obstacles does that create for us?
Sometimes there’s more than one oftentimes, in fact, there’s more than one and then thinking through it like systematically like, OK, for each one of those obstacles, what is our response for overcoming those obstacles or addressing those, right?
And so I think that, that if you follow that sort of like little method for breaking down the, the change or the, the the issue, then it gives you a lot of clarity on what can you do about it?
And it also enables you to better communicate to everybody around you, right?
And so if we think about, you know, breaking that down, you know, one example would be that, you know, like we had a client in several years ago where they they, they came to us to help design a solution that they, that they were wanting to build.
And a lot of it was based on AWS products, you know, Amazon web service products.
And this is sort of an example of like technology’s rate of change.
So at the beginning of the, the, the the product effort, when we were sort of in the design phase, we assessed certain capabilities that existed between within AWS.
Some of the ones that were really critical for this product weren’t really available yet and it wasn’t feasible.
And so we had to make the decision that that certain parts of this were gonna be built custom, right?
Well, fast forward into the product development stage, we’re pretty deep in and now a new product gets launched in Aws that actually does that sort of off the shelf, right?
And we already committed to a different path So then what kind of a challenge does that create for us?
Right.
So we had to stop and go.
Ok, we’ve got this new option available that wasn’t there before.
Do we continue down our current path or do we change directions and go use that?
And so we did something very similar with this kind of got clear on.
Well, why does this new products introduction present a challenge for us?
Right.
Or and does it right?
So some some kinds of obstacles that could create us, we’re gonna spend more effort and budget on building something that maybe we can use off the shelf for much cheaper, right?
Maybe there’s additional capabilities there that will help us down the road that we’re not aware of yet.
Are there potential limitations of that new product that we are not aware of that introduce some uncertainty or potential risk that we’ll be able to actually meet our objective again?
Because the last thing you want to do is change directions only to find out that that direction won’t get you there, you gotta go back to your original plan.
And so we approached this in a very similar way and ultimately, we made the decision that you know what, as much as we’ve got invested in this already going down this path, we know that this other path is gonna be better for us both in the near term and in the long term.
And so we discussed it with the client sort of weighed it down using this sort of approach.
And with the customer decided this is a path we’re gonna go.
So just a little bit of an example of how that may work in real life.
The V and the pivot framework is verbalized to stakeholders.
So this is really important, you’d be surprised how many times that communication or a lack of alignment among stakeholders really hurts product development and, and launch efforts.
And so again, what is it that we’re doing?
One is when we’re, when we’re, when we’re aligning stakeholders, we want to identify clearly for them what’s changed, right?
Sort of back to that earlier slide, what we did for ourselves, we wanna make sure we communicate that.
So they really understand exactly what has shifted in the landscape, the next one and this one is super important is communicate early like early, like I almost as, as soon as you know, it sometimes, right, communicate early and then often with stakeholders, a couple of reasons why that’s really important.
One is that the earlier you bring it up, right?
The more trust that you’re gonna generate with them that you’re seeing what’s going on out there and you’re being very responsive, a common mistake, I’ll see is, is a product manager will identify an issue and they really want to figure out all the answers and the solution before they start communicating to stakeholders.
And I understand that response.
But my experience has been that that’s a really bad way to do it.
I think it’s better to notify stakeholders and start communicating early about, hey, there’s a potential issue here.
This is what we’re doing to sort of figure out our plan forward.
And this is when I’m gonna get back to you with more details, right?
That instills confidence, right?
But if you bring it up really late, a lot of times the feedback will be well, if you already brought this up earlier, we could have addressed this or why did we burn all this budget in the meantime, why you already knew that this was gonna be an issue, right?
So communicate early and often with stakeholders and then create a plan for assessing their response and needed adjustments.
So this is about, you know, getting clear on the pitch on the the problem and then your plan for responding it and then communicating at the stakeholders again, like I I I I I would like to, to frame it this way.
What’s the problem?
Here’s potential solutions I’m evaluating, here’s the one that I think that we should go with.
And here’s my logic behind why I think that’s the case, right?
And so if you can sort of structure it like that a lot of times that helps get everybody on board and it encourages healthy debate about that course of action as you all align and then move forward, so verbalize stakeholders.
So the, the o is original, I cheated a little bit on this one.
It’s not the first letter in the title.
But so forgive me, hopefully, the information is is still good.
So re revisit the original goals and success factors.
So in other words, does the original premise behind our process, right direction and our decisions still stand or has something significantly changed that would, would cause us to maybe make a different decision.
So remember the example I made earlier about, you know, choosing this off the shelf product to kind of be the base of what they’re building and, and, and, and is that the original premise behind that being the right way to do this still stand?
Right?
Or in the AWS example, there was a product that wasn’t available then that is available now that meets our need.
So does that our original premise still stand?
In that case, it probably wouldn’t.
are there any adjustments needed to M VA S M VA s is what we call minimum viable analytics?
In other words, our core metrics like the key metrics that we are gonna look at to determine the success of our product.
Do we need to adjust what those are?
That could mean?
It’s because the objectives that we are focused on with this product might change as a result or how we measure it might change?
Right.
So do we need to, to make any adjustment to, how are we gonna judge success of the product?
And is there any additional validation needed?
So, I’m a big fan of trying to validate incrementally as often as possible.
So that we can really start to make sure that we’re going down the right path, we’re solving the right problem.
The feedback is what we need to see before we continue to invest money and resources in something.
And so at these, at these junctures where we’re sort of assessing things like this, I think it’s a great question to ask yourself is now that we know a direction that we want to go.
Is there a way that we can validate this?
So, for instance, if you have a competitor that’s introducing a product that is sort of going to compete with what your sort of core value prop is, then you may want to like like frame that along with your solution to get feedback from potential customers, get feedback from them, right?
It could be you prototype something out, show it to customers, give them the choice, understand why they would choose your product, right?
So again, one of the big things that we always talk about at N O A is minimum lovable product.
So making sure that you have a very convincing lovable product story, right?
Why is this product lovable by users?
Right?
And because love lovable very often translates into a successful product.
So, you know, seek out additional ways to validate if possible, the T and the framework is seek tangible clarity.
And so, and I’ll, I’ll explain what I mean, tangible in a second.
So one of the things I’ve seen is that where there’s fuzziness, where there’s uncertainty or a lack of clarity, there’s major risk to your overall product effort, right?
And so that, that Clari that lack of clarity control in lots of different ways, it could be clarity around what is lovable about our product.
Why are people gonna care about this?
It could have clarity around like who’s gonna actually buy it.
It could be AAA fuzziness around a road map.
What are we gonna release in each sort of stage?
It could have technical fuzziness as well, like we’re not real sure how we’re gonna approach this technically.
So any time there’s fuzziness, it’s really important to attack that and, and, and be very resolute in getting clear on that and getting everybody clear before you continue to move on, right?
And so, you know, like I said here, tangible clarity means everyone involved can clearly see that the path forward.
So this is sort of back to that other slide about communicating to all stakeholders and stakeholders can be developers, testers or Q A people, designers, architects, people from finance owners of the business, you know, different departments that, that are involved with the effort.
So, you know, creating that clarity for everyone, there really reduces the risk and helps make sure that you’re all aligned and that, that you can you know, really increase your odds of being a lot more successful.
I’m gonna a quick check in here, just make sure I don’t have any questions yet, but I keep going.
Ok, good.
And so, you know, some common things that you may want to ask yourself as you’re trying to make sure that there’s clarity is do assets need to be updated.
So assets are, you know, different, a variety of different things that you might use as part of your product development effort.
So an example could be, you know, some sort of a design prototype, right?
If you have a like a a Sigma prototype or an X D prototype, that sort of shows your product, does that need to be revisited and adjusted?
Does your technical brief, your architecture plan, does it need to be adjusted?
Right.
An example earlier about, you know, you know, third party products through AWS, right?
You need to revisit that architecture, given the new direction and then make adjustments and update that.
So again, it’s captured and everybody knows sort of what, what, what playbook we’re using, right?
is a new roadmap or timeline available for all to see.
So once you’ve assessed this, you’ve picked a direction, then, you know, recomm communicating out sort of your timeline, your budget resource needs road map, that kind of stuff would be really important and then is the budget approved for changes?
So based on this new change in the landscape and what your response plan is to that would that have an impact on your budget?
And if so do you need to get certain approvals or do you need to plan for that budget?
Right.
So in a large organization, it may be putting it through the channels of procurement or whatever that may be to help, make sure that the budget is in place to adjust for that plan and a start up, it might be, you know, have I raised enough capital to do this the way we originally intended or I need to revisit that?
So some examples around what does tangible clarity mean?
And so, you know, a final thought here on this one is, is, is don’t be afraid of, of, of change when you know how to pivot and, and resume with confidence.
So what I think we would like you guys to go away from this from is that you don’t have to really be afraid of a changing landscape.
It’s inevitable.
All we wanna do is try to arm you with sort of a AAA method or at least a a framework for identifying a potential change.
And then how do I work through that in sort of a structured way to help again, derisk and, and improve our odds of having a successful product.
So I think that’s, that’s all for the plan content.
I, I did have a couple of questions that got sent through, so I’ll, I’ll answer these.
And then if you guys have other ones, if y’all can take a minute to enter those into the, the chat or the Q A and I’ll take a look.
And so, I think Jordan, maybe this is the one that you had sent through.
Yeah, so, ok, so this was one that had been submitted earlier, I think.
So.
Thanks for sending this over Jordan when you’ve completed some development and a major change comes along.
How do you help stakeholders who control the budget?
Understand the cost of rewinding or reworking the product?
You know, I think one of the, the the the ways it’s worked well for me is helping to make sure that whoever I’m needing to talk with about this understands the why in a very concise way some of these issues can be kind of complex and a little overwhelming.
And so I think you gotta make sure that you’re boiling it down to make it really concise so that it’s easy to understand, right?
And if you can start with what’s the change, how will this potentially impact us and why do I think we should go this this route then it helps frame up the money conversation, the reality is that no matter who it is that you’re talking to about budget, the default answer is I don’t want to spend more money than we plan.
That’s always the default answer.
Right?
That’s human nature.
And I understand that.
Right.
But you have to give AAA more complete and concise logic behind why this is the right thing to do.
So, an interesting way to do that might be.
Here’s the risk that we’re like reducing, right?
Or here’s the potential problem we’re heading off by changing directions right now.
Here’s the reason we will probably save money by doing it this way, right?
Here’s the risk of not changing directions.
We may, you know, in, in, in increase the odds that our product doesn’t work out, right?
Or it doesn’t hit the target or it’s not lovable by users or we create ourselves a a technical, we paint ourselves into a technical corner, right?
Meaning we have to do significant rework later.
So I think kind of frame it up as clarity around the problem.
Here’s how we would solve that and, and here’s why that’s the smart decision from a financial standpoint.
I think that’s that’s how I would do it, right?
One last thing I would add is clarity around how you came up with your numbers.
That helps a lot too.
I’m a big believer in transparency on that kind of stuff.
And so explaining your logic, even if it’s wrong, at least it opens it up for debate using sort of a transparent approach and you can debate that.
And at the end of it, you know, you, it’s not whether they leave your numbers or not.
It’s about whether the logic is sound and, and that’s usually how I like to approach those is a lot of transparency around.
Here’s how I came up with my numbers.
Here’s the assumptions that I’m making.
This is why I’m recommending this and this is kind of how we came up with it and, and I think that’s a really great way to do it even if it’s internal or if you’re working with a third party.
There was another question I had here that had previously come up.
What is an example of?
here it is.
OK.
Yeah, this is the one Jordan I think.
Thanks for putting that in there.
What’s an example of a quick adjustment or band aid rather than a thoughtful solution?
You know, there’s, there’s lots of, there’s lots of good options for this.
I think one example that comes to mind is it’s a resource problem.
I need to switch the resource, right?
Sometimes that’s the answer, right?
But, but I’ve seen a lot of times that it wasn’t really the resource, it was either the process that was getting used.
It was a lack of clarity and alignment along the, the people who are key to the product development effort.
or like in the example earlier about, you know, like, like going down a path building on top of a third party product and then figuring out that it’s just not gonna get you all the way there.
You know that I remember in that, in that example, there was lots of conversations about, you know, this developer is just not able to get it done.
We need a different developer, right?
And that would be a shame because it turned out the developer that was on that product was actually very strong, like a great resource.
But, you know, we’re very close to thinking that, you know, the problem is really the resource when the problem was really the approach.
And so I think the band aid, another common band aid is let’s just work faster, let’s just put more hours, let’s work the weekend, like, like those kinds of things, right?
Like, so it’s easy to just get in that panic mode.
And especially if you’re, if you’re, you’re in danger of getting behind schedule is to just pile more effort towards it.
And, you know, an analogy I I use a lot is, you know, you need to make sure that your ladder is leaned against the right wall.
So what good does it do to climb the ladder and get to the top only to find that your ladder is leaned against the wrong wall Right.
And so that’s something, you know, some of that I think that applies here.
let’s see, we had a, another question, when is it too late to change the name of a product, who should be involved with a name change when you have shareholders who are recommending a name change?
You know, it, it sort of, it sort of depends my mind on this question goes toward, what’s the nature of the product?
Like, is this an internal product or is this an external product?
So, you know, the, the, the heaviest weight in naming a product for something that’s gonna be sold to the public, like, think like a B to C type of product or app.
I think that within the organization, whoever owns sales, whoever owns marketing probably has an outsized weight to their opinion on this, right?
So a product owner or product manager can probably weigh in on it and, and try to make their case.
But that, that, that strikes me is that sort of a decision that that would be hard to, to, to, to win that conversation or that debate, if the person on the other side of the debate is, is for marketing or who’s responsible for revenue generating, right?
I’m trying to think of like an internal example, you know, if it’s an internal product that was gonna get used, it would be maybe whoever is the one that owns the problem that, that product is solving.
So if it’s for internal operations or something like that, then, you know, I think, you know, that could be a good way to trace it is who’s, who’s the primary stakeholder who, owns the budget that’s funding this?
a lot of times that’ll lead you to the answer as well.
if it’s in a situation where it’s more of like a startup company.
big fan of focus grouping stuff, right?
And, and it doesn’t need to be these big fancy exercises.
A lot of times it can be some logo designs or taking the mock ups that you have with different naming options and, and share and get feedback on a few different options.
But back to your original question is when is it too late to change the name of a product?
And, you know, you could be pretty late to changing the product, but where that could turn into problems would be if a lot of your design in your software product is based around the name or the logo design of the name.
And it’s not as simple as trading out a logo or trading out like a color scheme.
It could be pretty painful.
So as an example, if let’s say that the design of like a web application was heavily structured around like the product name or like a logo, like for instance, if it, the header had serve some sort of embedded design, phrases and terminology that’s used throughout the application, have the name, you know, it’s not something that can’t be overcome.
It’s just it, it’s like it could be a little bit further reaching than just changing the logo that’s displayed at the top of the product, right?
So I, I there may be a little bit of a fuzzy answer.
It really depends a whole lot.
But hopefully that, that gives you a little bit of insight on that.
Let me make sure I answer the second part of your question.
We should be involved with the name change when you.
Ok.
Got it.
So I, I think I got the, the second part of it a little bit more thoroughly than the first part.
let’s see.
So I’ll mark that as answer.
great.
are there any other questions that anybody else have any other questions you’d like me to try to tackle or address here?
Give her another minute?
I think, I think that’s all the questions we got.
So, yeah, we went over on time a little bit, but thank you everyone for joining.
We appreciate it.
Hopefully you get some value out of this.
you know, as we’re wrapping up if you’d like to get on.
so we do a weekly email that we kind of tackle, you know, one topic every week.
We’ve gotten really good feedback on that from folks like you know, product owners CTO S, weed engineers, that, that really have given us great feedback.
They get a lot of value out of this.
We promise we’re not gonna like, like send you a ton of email, but, these are like sort of text only sort of, really sort of nuts and bolts type of email.
So, if you’re interested, reach out to me with a, a direct message on linkedin and, give me your email address and we’ll get you added to that list.
If you have other questions on this topic or, or topics within sort of digital innovation or digital product development.
I’d love to help out any way that we can.
so again, feel free to reach out to me on, linkedin, you see the link there, drop me a message and, we’ll, we’ll, we’ll set up a time to chat.
hope you guys got some value out of this today and I really appreciate you showing up and, watching and, let us know if there’s any way that we, we can assist you.
have a great rest of your week.
