Hi everyone. We’re going to go ahead and get started. I think we’re gonna go ahead and stream live
start joining in today. We’re doing another episode of ENO8 answers and really excited about this topic today. I think it’s something that that touches that sort of the core of what people are trying to accomplish when they’re developing new digital products and what we’re what the topic is today is, you know, building great products that Dazzle our customers and don’t blow the budget right and so again sort of two things that are
Really big fears and objectives at the same time for a new product development. And so, you
know really wanting to build the right thing build it something that’s useful for customers and also too
to do it without blowing a budget that that you have planned for the project and so Bear with us a little bit today. This is a new new sort of approach for us to do. No answers.
We typically do these two more like a webinar format that
we’ve tried live stream today and see if
that makes a little easier for some of our audience to join
in and see kind of
what we’re talking about. So if we have a few hiccups
here technically just just bear with us.
It’s kind of a little bit of a new approach first day that we’re
kind of excited to try out. So let me
I’m gonna switch over to share some slides and
so they put this over here and
all right, so
Like I said, it’s our topic today is you know secrets to
building great products that Dazzle
customers and don’t blow the budget just a quick little bit
of background on me. A lot of you probably already know who I am,
but for those that don’t my name’s Jeff Francis, I’m one
of the co-founders of no8 Red digital
Innovation Studio. We’re based here in Dallas, Texas me personally,
I’ve worked with over a hundred startups to help,
you know, build and launch their digital product as well as
you probably over, you know, 50 mid-sized to
Enterprise companies that are creating new
products or really significantly, you know, updating existing
products. And so
So let’s jump into our first point. So I’ve kind of
divide this at a four main points that I thought would be a good way for
us to to summarize how to really build great
products and do it within sort of a a
plan a budget a timeline that kind of thing.
So the first one is get clarity like and
and this can cover a broad bucket of
things. So I’m gonna kind of pull up a handful of questions that I’m
sort of referring to here when I’m talking
about getting Clarity and
Having Clarity or rather a lack of clarity is one of
the things that I think plagues product development, perhaps the
most because it can show up in so
many different ways. And so some common ones that
I think are really good to make sure that you really are clear about
and and have a good understanding of
is why are we building that?
So if it’s a new product understanding, why are
we building this? What is our what is our premise for thinking
that this is a good use of time and resources and
there’s different ways to go at that type of question one
could be you know that that we
are clear about the pain that we’re solving with our
product and we are clear that there are not great Alternatives in
the space, right? Those are a couple
of things I’d be looking for also too that we
have a good understanding of the user. So this last Point that’s on the slide
here. I’ll jump down to that one like having a good clear picture of
the user what problem are we solving for them? Why
are they going to really be excited about this and
you’ll hear us talk about that that we
really believe in building a minimum lovable
product and MLP versus
MVP, which is minimum viable product.
So, I don’t know our personal philosophy is that the MVP
is a bad way to build software. It’s outdated. There’s
a much better way to do it. And that is the m.
Be and so when you’re talking about minimum lovable product, you’re
really trying to boil this down to what is the minimum lovable
element of this new product
and by love what me that needs to be compelling enough
that people will want to use it and that they’ll be excited to
use it but also too that it
solves a significant enough problem that would cause
them to love it the first place. So why we building this
being really clear on that feeling strong about that? What
problems does it solve? Next one
here is have we defined success clearly, right?
How are you going to know if you’re successful if you
don’t Define it from the very beginning and you’d be
surprised to know that very often times people get super deep into product
development efforts and they really haven’t
even defined. How are we going to know if we hit the target yet
or not? Right and I can guarantee you that if you don’t Define
what the success look like, you’ll never
get there. You’ll never achieve it. Nobody will ever feel good
about it, right and then that sort of
Into this next point that I’m marked here
is are the stakeholders aligned. This is another one
that people don’t really think about when they’re setting out to build
something new but very often times
I misalignment of stakeholders kills products.
You could build something great, but if
stakeholders aren’t aligned it can still kill the
overall effort and so let’s talk a little bit about what does that mean?
It takes a lot of different team members or
players to launch a product. Right? It takes
someone with the vision. It takes money. It
takes resources it takes
Talent it takes planning, right?
It takes a
business view of
why are we building this? Right? So there’s always different
elements and most of the time these are covered by different stakeholders.
Right? And so stakeholders could be people
like investors a management
team, right the engineers that
are actually doing the development work the designers the
testing team the product owner.
You know, I would throw customers in that bucket, right? I think
that customers could be stakeholders, right especially if they
are people that you’re already working with in servicing
and you’re looking to build or extend products that
kind of thing so our stakeholders
aligned and so when we talk about how do
we get them aligned think through these other questions that we went through
right or all the stakeholders on the same page of this is a problem
worth solving. How do
we Define the success? What are our metrics? What are we going
to be looking for that kind of thing, right? So getting that
Clarity helps to ensure that that everybody is
is sort of Marching In step towards the
same goal. Another thing that I’ll mention here is a recent example is
is getting sign offs and
keeping the stakeholders updated on
the progress and how the
Visions coming together and so one example
of how this could show up would be, you know, once you
actually start designing and they’ll say that you’re creating a design
Prototype being able to share that circulated with
stakeholders get their buy-in that like, yes, we
are still on the same page that we’re
capturing. Our vision correctly can go
a long way to help make sure that you don’t go build something and
then later on you you identified. Maybe
there’s a disconnect. All right. So so get
clarity the first big Point let’s move on in
the next one have a plan. Right? So we need to
have Clarity Clarity gets us a lot of confident. It
helps solve a lot of the things that typically plague these
these types of initiatives and then next you
really want to make sure you have a good plan. So what does that look like? Let’s go
through a few of these one of my favorite things
that I like to talk about is a concept that that we
call validation Gates and maybe other
people have called it that or they have a different term for
it. I like to think that I kind of coined this
term, but maybe it’s out there already. So if it is I’m sorry for taking
credit for it. But what do I mean when I
A validation Gates validation Gates means being
clear about what Milestones or checkpoints do
you need to pass through and confirm
that you’re seeing what you need in
order to move on right? So let’s talk
about some examples. What could a validation gate mean one validation
gate could be that hey before we go to development we’re
going to have a design prototype and we’re going to focus group it
with some potential users engage the
feedback on our our hypothesis of
what is our minimum lovable element of this
product, right? Like we’re gonna have a prototype we’re
gonna show it to potential customers and we’re
going to get validation from them that confirms that
that our hunt. Just correct, right that could be a validation
gate and so once you do that a couple
things will happen one is you’ll show it to them. They’ll
go crazy. They’ll love it. You’ll feel really good about your concept and
you’re gonna go to the next stage with much more
confidence right another thing could happen.
Prayer, you know, they’re kind of they’re kind of cold on it right? Maybe
you don’t maybe maybe they look at
it and they don’t think that it’s as good of a solution as you might
think it is, right and then you just need to huddle up and figure out
like, hey, let’s examine this feedback figure out what we
need to take from it and perhaps readjust our
approach or in extreme cases.
Maybe you decide not to move forward on the initiative, which if
you’re doing it at this stage that’s success, right? It’s
better to figure it out get your validation or
the lack of validation as early as
possible.
So create these validation Gates
figure out like at what point can you get the maximum amount of
validation for the least invested time money
resources and keep doing
it never stop this right? So some other
examples of validation Gates could be you know, you’ve done
the design prototype you focus group it you build
like your minimum lovable product.
So what’s the key killer feature build something
that works go back to users get input on
it get your stakeholders to look at it get the
feedback. If you like what you’re seeing and move on
to the next stage, which is, you know, potentially adding new features,
right? And so I’m a
big fan of trying to figure out validation, but then
also keeping a clear picture on where am
I where am I gonna start to generate Revenue, right?
Because it has to be on your plan for validation Gates
right as soon as possible figure out. Is there
a way to generate revenue from this product in most
Some exceptions could be if you’re building an internal
product perhaps that may not be like the key
driver, but you still need to define success and you still
need to have validation Gates.
Another question that goes along with knowing whether
you have a good plan or not is what we
build first right? Like being really clear
about. What is it that you need to build?
What order do you need to build it? And how are
you going to release? It could also be a part of this I think right. So again
back to our concept of getting Max
validation with minimal effort and investment. So
looking at your roadmap understanding what order
are we going to build things in and
And understanding like maybe what what the first thing is that
we’re going to build, right?
So so what do we build
first next is what technical approach should we use? Right? This
should be a part of your plan oftentimes projects
that even our successful initially
fail later on because they
really had major technical or more architectural
type of issues. And so having a
clear plan and knowing that you’ve dug into that to a level that’s sufficient
for you to have confidence and flexibility
built into your approach keeping in
mind. What are you trying to accomplish in the near term? And
what’s the longer term Vision kind of looking at it through both
of those lenses is a great way. I think to look at your technical
approach.
I could talk a lot about that point. So if you guys have questions on
that ping the chat well, we’ll come back to some of those another one
is do we need a design prototype, right? Why
do I mention this as part of a plan
that may seem out of place to some of you but here’s why
I put this on here.
A lot of the effort and coming up with the plan is
driving that alignment that I talked about
under our first slide, right? And I find that
a design prototype is one of the best
tools in our Arsenal to help Drive align across stakeholders
that all communicate very
differently and have varying Comfort levels with
Technical and user experience elements, right
and so a design prototype as
part of the planning phase really brings
a lot of that Clarity to what exactly
are we building? What are we building right now? And
how will we know when we’ve achieved
that that step right? And so I’m
a big fan of the design prototype being
part of this sort of plan phase, right?
And this is the one that everybody’s gonna be asking about how much budget do we
need? So how much is it going to cost? And that’s not not exactly
a simple question. We’ve got some pretty good content that
we’ve written and spoke about about why
estimates for digital products are so widely varied
based on going to different partners
or checking out different options to have it built and there’s
a lot of real good reasons for why that is the case. So having
a plan and having a good plan
means you have a high degree of confidence that your budget
number is is going to be pretty close, right? And
so
Some things that think about there when you’re coming up with your budget is understanding. Like
how did I arrive at these numbers right and
and you know doing sort of
a Bottoms Up kind of estimate and you know,
another way that I like to go about this is a lot of times is looking at what
kind of budget we have for each phase or each one of those
validation Gates sort of talked about earlier and and
and and tying our budget
to meeting validation Gates. I always like to say that
that people feel a lot more confident about investing
additional budget if they are hitting
targets for validation before
they have to make their next investment,
right? And so it builds confidence with the
team builds confidence with the the investors or
the executives that are approving budgets and so understanding, you
know, what is this budget tied to
in terms of success or progress towards our
product.
And the last one here is how long will it take? Right so timeline again chopping
this into pieces. How can I achieve my goals how much
time I gonna need to do that? And you know, like really
understand where your numbers came from one one question. I’ll
toss into the mix here before I move on to the next point is when
we’re talking about budget. We’re talking about timeline or
talking about the technical approach
that matter one question. I like to ask our team
and everybody involved is
if we are going to be wrong.
Where would you guess today that that probably is going
to happen. Where are we going to be wrong? Right and and
really that sort of a teaser question that just serves to
understand different point of views on the team and you’ll
be surprised the insights that you get a lot of time when you ask that
question. So that question is, you know, if it turns out that we’re wrong about
budget.
Why would you guess that would probably turn out to be the
case or you know on the technical approach if we
turn out to be wrong about our technical approach?
If you had a guest today, where do you think that would
come from right and then just digging into that and examining? So
a good question to ask your team
now?
So my third main point is assembling the right team.
So we started off we we have Clarity. We
have a plan now, we got assemble the
right team. And so what kinds of things do we think about here? We pull
up a few questions here and we’ll go through these together.
So first question I put is what
roles will need to be accounted for. So this is basically taking
inventory of
what are we going to build and what type of team is going
to take to build it? Right? And so some examples
of of roles or talent that
you might need to have is you’re gonna need to have people
who are the Visionary right both Technical
and design Visionaries. Right? And this
could be an addition to a product Visionary. So someone
wearing the product manager or product
owner role is a must have you’re probably gonna
need someone on there that is is a ux or designer that
that’s gonna help actually create the
visuals understand the user flows and that’s
probably a deeper topic we can I don’t
want to get into that too deep but but really making sure you understand these
things in between user experience and you are
more of a visual designer and you’re gonna need both of those
elements. And so having someone to cover that properly
having someone to cover the technical design
is gonna be important because you’re gonna do the development
work who’s actually going to be doing
coding who actually is going to be the person that’s ensuring quality and
testing and so
I would encourage you like be really honest
about you know, what those roles are and do
you really have that covered with your current team?
Right? And so that kind of bleeds into the second question there I had
about what specific Talent will be really important. And why
do I say we really important different products have
different challenges and different products
also have different aspects of them that make
them important or valuable. Sometimes it’s
particularly technical right? Sometimes it’s
it’s more focused on user experience
or the design or the overall flow of
the application, right? And sometimes
it can be both right but if we look at
this and we understand that, you know, for example, this
product has something very unique about
it technically or the technical aspects of it
or the Lynch pen of success, then you’re going
to make sure that you’ve got specific Talent is really
going to be able to cover.
And that you feel very confident in their past experience
and capabilities that it’ll apply
really good to this scenario. And so, you
know looking at you know, what is it unique about your product and
what specific Talent is going to be really important there.
It’s gonna be a question that you want to make sure you feel comfortable about and then
who do I already have on my team maybe as you’re
looking around and you’re deciding what team am I gonna need
for this? What specific Talent does that that gonna
include you look around at your own team and and
determine do I already have that right? Sometimes you
will and larger organizations. Maybe you already have
this.
But don’t be tricked into thinking that just because those people are on
your team. That means they’re gonna be available. Right? So that’s another
thing but big organizations have very talented and
large development teams a lot of times, but the
problem is that they’ve got other stuff on their plate. So if you’re
trying to take on a new product initiative, I see it a lot
where these initiatives keep getting pushed to the back of the line because
there’s other more pressing stuff that keeps jumping the line in
front of them. So not only is it do I have them on that my
team, but are they gonna be available and are they
gonna be able to give enough bandwidth and attention to this to really do it justice, right?
If not, you got to figure out how to cover
that where the holes in my team. So that could
come from you know the point I just mentioned, you know, I’ve got
the talent but they’re just not available or they don’t have the bandwidth or it
could just be playing out. I don’t have that person on my team right? Maybe
this scenario is a little bit more common with startups or
smaller companies where you really have to have some of
this super skilled super Niche more rare
type of talent in order to
Cover it properly, but you don’t really have the
need to have that person full-time on your team. Right? So that’s
a whole you need to cover it and figure out what your plan
is for that and then the last question here is in assembling
your team. You know, what if I miss that on the team
I’ve created that’s gonna happen and and everybody would like
to think that they’re gonna knock it out of the part with the first version
of the team that they assemble but that’s very rarely
going to happen right the times
that that do that does happen is gonna be
where you’ve got 18 that has already worked together
in the role specified on multiple
projects or for a very long on
a previous project before that would be a scenario that would
would maybe give you a much better odds of
success of you know, hitting the
Target right out of the gate with sort of the first version of your team other
times. You’re just gonna need to make sure that you’re
assessing and you’re you’re being
really honest about like how the teams performing
Are all the roles getting covered and and
then making adjustments along the way so how do you
do that a couple of quick thoughts on that? We could talk about that one a whole
lot also, but just to give you some tips on things
that I would go towards if that was something I was saying is I
would try to first start by being really clear
on what are roles on the team, right? And if
I’m seeing problems or we’re not getting our results one. What
is the result that I was expecting to see that? I’m
not seeing and can I easily Trace that
Miss expectation to one
of the roles on the team forget about people
let’s just focus on roles first, right? So if for
example, you know, we’re not starting
and stopping friends on time, right? There’s no schedule that could
be a role for the scrum master or the project manager on
the team. So first, I’m gonna go. Okay great. Do I have somebody that
specified to that role? If if so then let’s
examine more are they clear on what’s expected
out of that role? If not, I need to go communic.
Take that tighten that up if they are clear then do
they have the capability to do this, right? So going through
these these sets of questions to examine. Where
is the the hole
on the team and what kinds
of adjustments do I need to potentially make sometimes it’s as
simple as just having a conversation and getting on
the same page about expectations.
Of the times it might involve making a change to to the team member
in some form or fashion, right? So that’s
assembling the right team. So we’ve talked about get clarity have
a good plan assemble the right team. Now,
let’s close the loop assess results and make
adjustments. And so, you know, I’m a big fan of
kpis and measurements, right?
So we’ll talk a little bit about that. So,
Here’s here’s kind of the four main points. I’m going to talk about on this bucket. So
assess results and make adjustments know your key
metrics. So how do you know your key metrics? Well, go back to
the first slide and think about defining our success criteria if
we can clearly Define what is
success then the next step is to determine. Well, how
are we going to measure it? Right? And there’s your key metrics that’s usually
that the simplest way to arrive at those. Sometimes there’s
some technical challenges to getting to well
exactly. How do I execute on some sort of data capture
for Gathering that information but knowing
your key metrics to start with well then allow
you to take the next step figure out. Well, how do I measure that, you know
from a execution standpoint, but then be reviewing this
right you need to be looking at it regularly. So you
understand how you’re tracking towards those goals. These can
also be tied to the validation Gates that
we talked about earlier, right? The next one is
involved stakeholders in the review. This is super important right
for instance.
If you have investors that aren’t looking at the data with you,
right then chances are they’re not going to be very satisfied
right? Because one they’re not included in
the past or the process of evaluating it
right. So they may make the assumption that nobody’s looking at
it next. They need to be incorporating the
conversation around. How are we doing? Are we doing great. Awesome. How
do we do more of it? What’s the next step or are
we off track? Are we not hitting our targets that we wanted
right? Great. Let’s bring it up and have a
plan for how do we respond? Either way having stakeholders
involved in this review process and I’m
big fan top to bottom right and includes Engineers
includes QA includes product people. Please design
people involve the team in reviewing your
metrics and understanding how we doing together because it
is a team effort next is revisit revisit your
success criteria, so that kind of goes along with looking at your
metrics, but every every time you do some of these assessments
and these look back yet.
Back and remind yourself. What was our original goals right like
and how are we tracking towards that success criteria?
And then the next
Point here is looking forward, right? What’s the next validation gate?
So we’re looking back seeing how we did make an
adjustments if we need to now, let’s reset
and look forward. What’s our next objective. What’s
our next validation gate that we need to pass through
right and I mentioned it earlier but think
of these validation Gates, I think a good way to think about like, what is
a validation gate is when’s the next time you’re gonna have to
go back to get additional budget approved right? Because
nothing will help you with getting
budget approved like being able to demonstrate a track
record of setting success criteria and then
crushing those goals. So when you
think about validation Gates think about like at what point am I have to go back
and like get like another Concha funding approved for another budget approve
that kind of thing. Those are typically really good places
to think about your validation Gates.
And so what is next and then Define that objective
and then make sure you’ve got a way to measure that right? So
let’s recap we’ve got basically four main buckets
get clarity have a plan assemble the
right team and assess results and make
adjustments.
Hold this has been helpful guys. I’ll take
a quick look in the chat and cut over for my slides to
see if there’s any questions that are coming through in the chat and I can
try to address some of those. So just bear
with me second. Let me take a look over here and kind of
looking I’m not sure if I’m seeing any questions coming in but
You know, I’ll just kind of jump onto our next slide here. And if I see something come in
I can I can always cut right over.
So, um, you know, if you have any questions on
the stuff that we covered today would love to hear about those,
you know, drop drop us an email at info at
no8.com. That’s e n o
and the number eight.com. You can drop
an email there one of us from the team. We’ll see it we’ll respond
back and then your course
reach out to me and connect on LinkedIn. We post a
lot of this kind of content. We love to to just sort of
facilitate the conversation and as you can tell love talking
about this kind of stuff, so would love to hear from you actually looks
like I had a question just come in so say hey
Jeff, how would you suggest these to find the cut list
of features and MLP versus waiting
longer to announce? The product
is a good question and we get this this is common all
the time, right? So
Basically, you know what? What and I
think this came in from town so Tim saying how would you suggest companies
to find the cut lists of features for
the MLP versus waiting longer to
announce the product so really the the decision of
should I expand the scope and
include more in there which is going to probably push my
timeline out and defer us
being able to get something out versus move
our cut line up on our feature list
and leave some stuff off generally speaking.
I I really try
to push as hard as possible to move that
cut line up to what is minimum lovable, right?
And so when I think about especially v1s
of products that we’re launching I
try to really reduce it down to like, what is
the killer feature like even if I think about this like
like I can only launch with a feature that’s
compelling enough to just get people to start using
Something that they love and then rapidly iterate
or expand on it. Can I
reduce this down to a feature which sounds kind
of ridiculous but if it’s more of a thought exercise think
about like if I had to choose it down to one. What is
The Lovable thing and that one needs to be slot number
one usually
Be on that like not trying to figure out like
what aligns with the validation Gates.
You know, like looking at like from a business standpoint,
what’s most important in order
from my business to be able to take the next step?
So take the product backlog out of the picture entirely
just look at this from a high level business standpoint,
right? So I recently had a
conversation with a client where they’ve got a product they’ve done
a great job of getting it out into the market with sort
of a soft launch and fortunately slash.
Unfortunately. They’re starting to get a lot of user adoption.
Right? And so now they’re looking at this going. Okay,
like what do we need to prioritize to do next and
the batch of work that we we sort
of work through identifying and
estimating for them came out to be like really big a lot bigger than
anybody thinks is really what we need to do. And so we just we simply
had a conversation about revisiting like what is the business need
right now, right and the conversation started
moving towards. Well, you know, like we’re just
kind of getting an initial version of this end
of the market.
Place the founders are self-funding this
stuff. You know, it’d be it make us all feel a lot better if we’re
generating Revenue. Okay, good good way
to think about this. So what is our obstacles to
generating Revenue right now, right? So what we need
to get subscriptions in or all we need to get this other feature in so we now we
start to think about okay. What’s the shortest path between we were
starting to get really good validation from like a
set of users from sort of a soft launch,
but now we need to generate Revenue what’s holding
us back on that after having that conversation where you’re
able to really carve up that backlog and reduce it
down to just one or two features that were pretty manageable and
now we get to another validation gate.
So I hope that helps them, you
know, that’s kind of how I’d go to it is a couple of things about like,
you know, looking at it through the lens of validation.
The business objectives and then when all
else fails create a time box and force yourself to make it
fit so that would be my last my last step.
Let’s see again. Another one came in. Hi, Jeff.
What are the major?
What are the major pillars for a successful project like technology team
stakeholder planning? What
are the major pillars for a successful project? So
I mean in terms of pillars I would call these pillars
right Clarity solid plan
the right team and a way to
access your results, right? But within those there’s some other
Nuance that might be worth talking about.
You know, we not not to like, you
know, like like promote like our services too much
but we have a really unique offering called Innovation lab
and it’s really focused on the these first
two points creating Clarity and then having a good
plan and so, you know having Clarity
around, you know, the product Vision itself,
but also to the the technical elements
of it the design elements of it. So what I
what I like to do to be able to sort of check those
boxes and feel like I’ve done enough for that
is is looking at a certain set of artifacts
that we typically go to I’ve got
a great slide for I don’t happen to have it in
here. If you’ll direct message me or send us an email
to info anyway.com. I can send you the slide
but some of these artifacts that we create that we really
think helps with those pillars is things like
Having a high level, you know architecture right?
I’m not talking about super low level I’m talking about at least
high level and then defending it, you know across a couple of
different stakeholders. Another one could be a design prototype, you
know, this could be like a figma clickable
prototype some people use like Adobe XD
or Envision. So there’s a lot of tools
for out there but having a design prototype, I feel
like creates a lot of clarity and helps you get to a better plan right
other ones are being clear
on your user personas. The user Journey that
that’s why it’s massively overlooked by
people but I think is really valuable is mapping
that user journey and then using that user
journey to identify where the real opportunities are
the best serve the user and provide a lot of value. So a
lot of people just skip that step or don’t even know what it is. So
use your Journeys are really important most Engineers
go to like technical design like architecture
diagrams that kind of stuff like
important there is I think the the high
level of it is super important really early on but
then you need to progressively revisit it and
make sure that aligns with your immediate needs and your
long-term vision and so
You know one last point that I’ll throw in here. There’s probably worth mentioning is that
there’s sort of this these two different School of thoughts that
that compete with one another a lot of times. There’s more
of like what I would consider like an older School thought school thought
which is more over waterfall approach, right and
then on the other end of the spectrum you have more of a pure
agile approach and there’s things that
are great about both of these different approaches. But the
reason why I mention it here is that on one end of
the spectrum waterfall is very heavy on doing all of your planting
up front having a lot of precise detail on every task and
every step of the way agile is
a lot more loose right and and it’s more adaptive
along the way.
Here’s the pitfall of both of them and a quick
a quick take from me one is that waterfall? It’s easy to get
bogged down and planning and you never actually move the the
effort forward right or you spend
so much time and money on planning right that you evaporate,
you know, your enthusiasm and your budget and
your resources before you can actually even get something in the hands of
users to validate on the other end of the spectrum with
agile. I’ve seen budgets completely get
blown by just angeling your way through product development.
And so if you’re if you’re you’re taking
more of a hard agile approach we tend to
do more Agile development. It’s still
important to have at least a sufficient level of the
direction that you’re going having your North Star and
the form of these plants technical plan that
you’re you’re design prototype, you
know, you’re validation Gates you still want
to prioritize getting at least a sufficient level of
depth there where you can guide the agile and
kind of
Strain it to budgets and time boxes
that are a little bit easier managed. So
I’m not sure if that’s exactly your question, but hopefully that
helps. Let me see here if we got another one before
we start wrapping up.
It was the two that I saw it looks like somebody might be
typing a new question. So I’ll give them just a minute to see if that
shows up. If not, we’ll go ahead and
kind of wrap up.
Right. Well, I think we’ll go ahead and wrap up here guys. It looks like that
looks like it’s always typing a question, but I don’t see it coming
through. So we’ll go ahead and move on. Just kind of wrap up for you
know, again, thank you for joining. I hope there’s some
information in here that might be a value to you guys. If you like it. Let
us know if you don’t like it. Let us know that too be interested
in your feedback. Please share it if you think there’s others that
that might be interested in this please share and
and pass the information along. I think this will get posted the
LinkedIn, so you’ll be able to share the link or tag somebody in
the comments, which is a great way to bring their attention to
it. If you have any information if you’d like
to have any information on our Innovation Lab at
NOAA, it’s awesome. We love to
talk about it. I love talking about it. So if you
want to check out some high level information about your website at noaa.com
slash Innovation Dash lab,
it’s got some great information out there. And other
than that, we hope you enjoyed the information today and
thank you guys again for joining us.
To you soon.
