Hi, everyone. We’ll go ahead and get started. Welcome back to another one of our ENO8 answers. Today’s topic is another one that we get asked about really frequently. And so we thought we would dig into it. And what’s kind of neat about the, the session we put together today for the workshop is that we’re, we’re, we’re gonna have a little bit more of an interaction from your side of sort of self scoring and rating on some things. So I’m kind of excited about trying a little bit different format today on this topic.
The topic that we chose is how confident are you in your software development team, right.
And we’ll see that this is talking about, you know, this could be in house teams or this could be, you know, an external partner or vendor that maybe you’re working with.
I think a lot of what we’re talking about today will cover both of those different types of scenarios before we dive into that.
For those of you that don’t know, there’s a little bit of info about me.
My name’s Jeff Francis.
I’m one of the co-founders of N 08, we’re a Digital innovation studio and E 5000 company.
We’re located in Dallas Texas.
Me personally, I’ve worked on launching, you know, over 100 probably over 200 different digital products over the last seven years.
And so really love the digital product space, digital innovation in general and just hoping to maybe answer some questions and, you know, provide a little bit of value for you guys that are kind of on this journey of, of launching a new digital product or, you know, significantly rebuilding or reimagining an existing product.
so let’s let’s kind of get into today’s topic.
so, you know, how do you know whether you should be confident in your software development team or not?
This is something that, that kind of comes up in lots of different ways.
And so we wanted to tackle that today.
The format of this is like I said, a little bit different than some of the other N 08 answers sessions that we’ve done.
what we’re gonna do is take you through a series of eight different questions that I want you to ask yourself and just kind of think about some.
And then as we go through those, I’m gonna ask you to give yourself sort of a score from 1 to 10 on each one of these questions.
And then towards the end, we’ll tally that up and kind of figure out like, where do you sort of sit in terms of your confidence level and, you know, along with that potential risk that you have with the team that you’re working with right now.
So, questions, we’re gonna rank yourself on each of those and then we’ll tally those out towards the end.
And like I said, this will work in a small start up.
They’re pre product, pre revenue and you’re just starting to get going and you’re talking to people, I think this will help.
It’ll help you.
If you’re building your first version of your product, it’ll help you if you are a much larger company and you’re working on ongoing product development, Or doing a significant rebuild.
this goes for assessing your confidence in your in house team or an external partner or even a blend of both of them.
I think it’s, it’s, it should really cover all of those different scenarios.
Let’s talk a little bit about sort of the grading system that we came up here.
You, you can see we’ve got sort of this sliding scale going from one on the left to 10 on the right.
And if you think about it like like a 10 in this case means complete clarity and confidence, right?
You have 100% confidence in your team at this point on this question, right?
You know, a one is sort of a, a complete mystery.
You have no confidence in the answer to that question five is of course, sort of halfway in between where you’re sort of decently clear.
And you have some confidence, but there’s probably some shoring up to do, but just as important as the grade I want you to ride out.
Like why you’re giving yourself the grade, like, what’s the driver behind?
Why you’re scoring yourself that way?
And it could be, you know, just a couple of bullet points or maybe a sentence, something like that.
But, but grading it sort of gut feel right out of the gate, like with a number and then sort of a little bit of a thought on why am I giving it?
That number one other note you’ll notice is we drew a sort of risk line from the top left down to the bottom.
And what that’s sort of representing is that as you rate higher on this scale, the risk level overall decreases.
And I think that a large part of the the digital Innovation game is managing risk, right?
And I I frequently say it that that confidence is the antidote To risk.
And how do you get confidence is by having a lot of clarity.
So get good clarity on things, build your confidence, the whole team’s confidence, which results in being sort of a good antidote to risk, which is inherent in any kind of new product development effort, right?
So the goal being we want to get to 10.
So let’s kind of see how we’re, how we’re doing.
We’ll go into first question.
So this is sort of two questions.
So I cheated a little bit on some of these.
But question number one is sort of two questions relating to the same thing.
How clear are you on your product timeline right now?
Right now?
How clear are you on your product timeline?
That’s not just the next checkpoint, but overall like the big like milestones or deliverables launches.
How clear are you on that timeline?
And along with that, how confident are you right now that you’re actually gonna hit that timeline?
And so, you know, I think that that the confidence in this bucket can sort of come from sort of two different two different options, right?
One, if you rate high or low on this, it could be based on your track record with the current DEV team again, in-house vendor blend doesn’t matter, right?
So if you have a track record of setting dates and hitting dates, that’s a good, that’s a good way to build like a high confidence score on this question, right?
However, if this is a newly formed team or a new effort, or you don’t have that track record, then maybe you can, you can have a high confidence score on this with a lot of visibility and clarity around what work’s being done.
What’s the estimated effort for those work bodies?
And do you have good clarity and completeness of what work needs to be done and the associated effort, therefore, timeline that go along with those?
So you may Get your confidence or lack of confidence from sort of one of those two main elements.
So take a minute here and give yourself a score 1-10.
How confident are you in your product timeline?
Or how clear are you on your your product timeline?
And how confident are you that you will hit that question?
Number two, how confident are you that your architecture plan or your tech plan is solid?
How confident are you that it won’t need a significant rebuild or reactor in the near future?
This is a big one.
I see a lot of products get launched, even really successful ones, but they have a lot of pain after that launch because they get great adoption and they find that they have a lot of problems there that are gonna result in having to significantly rethink their architecture or a big part of their tech plan, right?
So what’s your confidence right now that you’ve got a really good architecture or technical plan that meets your needs today and will meet your needs in the foreseeable future.
And so we see this all the time, so this is going to really think about you know, a perfect example here is, you know, launching a new product, you get great validation.
Users start to come, you’re needing to scale and all of a sudden you’re having issues with stability, you’re having a lot of problems with making changes and updates to the software rapidly.
Those could be a couple of warning signs.
We’ve got a whole blog post on this.
So if you guys want information on that message us or, or send us an email and we can, we can get you some additional information on sort of what to drill in on on this area.
Another example here is like, you know, I I I see a lot of people place confidence in one architect, right?
This is sort of like the the Superman theory, like we’ve got a rock star architect that’s really talented, really good, knows their stuff and all of our confidence comes from that one person that may work out great.
There’s a lot of those people out there, I’ve even worked with a lot of people that I would put in that bucket.
But even those people that are superstars at architecture and guiding the direction there.
I find that it’s a great investment to get multiple voices involved in these decisions early on, right?
And these are not needed consistently, but at, at certain inflection points where you’re making key decisions related to architecture and stack and some things like that, right?
So whenever a lot, what I’m a big fan of is, is, is you may have someone that’s doing the heavy lifting on this, but bring someone else that’s also smart, even if it’s a, you know, a, a contractor or a consultant to help sort of validate that approach, try to shoot holes in it and ask questions or find potential issues with.
And if anything else, it just creates some good healthy debate where you flush out things when it’s, when it’s much cheaper to make changes to your plan.
So involve a few voices there, I encourage a lot of debate on this to help, you know, make sure you have a better outcome.
Go into question.
Three
How confident are you that the advice or insight you’re getting from your team is unbiased and accurate?
A lot of smart people, but we have natural human bias, right?
And again, this applies to in-house team and external, right?
Sometimes advice on things like like let’s take the last question about talking about an architecture or technical approach.
If someone’s on your in house team and they recommended that approach, there may be some hesitation in calling it out that it’s got a lot of problems, right?
That’s that’s natural, that’s human nature, right?
If it’s an external vendor, something as simple as, hey, can we speed up our timeline by adding some additional developers to the team?
Right?
There’s a natural bias there to potentially, you know, be OK or encourage adding bandwidth to the team because that’s good for the vendor, right?
It may be good for the, the customer, the customer you in that case.
But, but again, it’s how confident am I that the advice I’m getting is best for our product and it’s unbiased and it’s accurate.
some warning signs here is when people, always have an answer.
You know, I think, I think the smartest people that I’ve worked with in this space, they they very frequently will answer that they don’t know the answer, right?
Or they’re gonna have to get back to me that builds trust when I feel like somebody can tell me, I don’t know the answer to that or I’m unsure of the answer or I have a thought, but I want to research it a little bit or validate it and come back that builds trust with me.
In the case of the vendor example that I used if I’m asking them, hey, if we can move our time line up by adding more developers, is that a good idea?
And they tell me no, and they give me an explanation of what I should do instead.
Again, that builds trust.
So, you know, that’s a little bit of a track record thing.
But looking out for examples or signs that people give you good advice for the product and for you that, that is free from bias, right?
And that it’s accurate So again, rate yourself 1 to 10 on this bucket.
How confident are you?
The advice is good.
, next question.
Do you know exactly how much money it’s gonna cost?
Right.
And that’s a broad question, how much it’s gonna cost to get you where?
So maybe get you to a certain checkpoint or a certain what I call like validation gate.
Maybe it’s how much money to build my M V P, how much it’s to, to do this refactor or whatever phase it is, how confident are you that, you know exactly how much money it’s gonna cost and then, you know, sort of the next level of that is how much money at each stage on its own, right?
And this question in a lot of respects is very similar to the earlier one we had related to timeline because timeline and cost are really closely conducted, right?
And so, if you’re missing your timeline, you’re probably gonna be blowing your budget, that’s usually how that works out, right?
And so question two really sort of hinges on, you know, again, clarity, how detailed are the cost breakdowns that you’re reviewing?
you know, that, that clarity and that confidence breeds a lot of confident or that, that clarity and that transparency breed a lot of confidence, right?
And so, you know how detailed is information you’re looking at, how well thought out are the components to the, the plan and the cost some, some examples of things I frequently see people leave out is they build their cost around just the estimates on feature development as an example, right?
And, and I think that once they’re done with feature development, then they’re done, right?
So that’s how they calculate budget.
That’s a rookie mistake because you, you, you never get to feature complete and then are completely done.
You, you need some sort of hardening period there where you’re doing testing, you’re bug fixing, you’re doing some U A T getting feedback, addressing issues, you’re prepping to go live.
So you might need to do things with your environments.
There’s other work that needs to be accounted for even beyond sort of being like quote feature complete, right?
And so, again, just as an example of timeline, you know, confidence from these can kind of come from these two areas, right?
You may have a track record where you, you’ve worked with the team before you’ve determined budgets and then you’ve hit those budgets, you know, with high accuracy in the past that could build confidence on this scale.
The other option is I just got a great degree of clarity and I’ve scrutinized it with the team and I feel like it’s really complete, right?
So, again, rate yourself 1 to 10 along with a thought or some bullets on, you know, why are you, why are you a 10 or why are you a six or why are you?
A two?
Moving on to question number five, halfway there.
Does any, does everyone involved in the project have the same vision?
How sure are you that everyone is working toward that shared vision?
There?
There’s been quite a few studies out there.
I think Deloitte had one.
It’s not too long ago that they, they, they had a metric on this that was really high in that.
This was one of like a, an a of a failure of alignment among key stakeholders, one of the biggest contributing factors for why product development efforts fail.
And I I can, I can speak to that from experience because there’s so many different people who have to be perfectly aligned on.
What are we building?
What’s getting delivered?
When is it getting delivered?
What’s it gonna include?
Why is this product significant?
Why is it lovable by users?
There’s all these different elements that require lots of different types of people and resources to be on the same page?
And so how confident are you today that everybody is completely clear on the vision that that vision is the same for everyone, right?
You know, it’s very common for developers, they’ll work on something.
Maybe they even make some decisions along the way, like thinking that they’re making the best decision, but it turns out to be out of alignment with the product owner or the founder or an executive that’s really like got the budget for funding the project that that happen, happens a lot.
How clear are you in laying out the vision for the product and ensuring that everyone is on board with it?
Right?
How confident are you that your entire staff buys into it?
A lot of these products are successes on the product team, but when it gets delivered and the the key stakeholders, you know, like usually the, you know, founder or like a a high level executive that is, is, is really keeping an eye on this, that they are not in alignment, right?
So in their mind, it might be a failure.
So how are you heading that off?
Just a tip here that, that I find really useful is I think design prototypes are a terrific tool on this front to help create alignment.
You know, I say it a lot that like you’ve heard a picture is worth 1000 words.
Well, I mean, in the case of building software having a really good design prototype, that’s, that’s pretty complete, is like worth a million words, you know, because it really does a great job of bridging the gap between product folks, Q A the developers, stakeholders, even potential customers that are gonna expect to use this product.
So if you have a good prototype, you can work out a lot of things when it’s a lot cheaper to make those changes and it really creates this alignment that we’re looking for here.
So again, give yourself a score of 1 to 10 along with your notes and we’ll move on to question number six.
How sure are you that you own and control all of your product artifacts?
Now, this one may surprise a lot of you of like, of course, like I have control of all of my artifacts, but this comes up so regularly that I wanted to put it in here to make sure that, that you can rate yourself on.
How confident are you that you can put your finger on everything and that you have ownership and control over all of your different artifacts related to the product.
So what do I mean when I say artifacts, this is stuff like your source code, right?
You’d be surprised how many time, especially startups start building a product and they don’t even have access to their source code, right?
Like we, we really encourage, you need to have control over those artifacts all the time.
Even if you’re working with an external vendor, you need to grant them access, they need to work off of your, your repository as an example, right?
So that could be source code that could be design artifacts, design source design files, documentation on things.
We even go as far as having the clients have their own instance of a lot of the tools.
So we, we, we, we’re big fans of the Atlassian Suite.
So we use Jira and Confluence.
It’s really common for us to go ahead and of our process, create those accounts for the client.
So they have it set up and we’re working off of their accounts because the goal is to build a successful product.
And as you achieve that, it’s, it’s gonna probably make sense to eventually build your own product team in house over time.
And so it helps set those processes and make a natural transition to that in house sort of model over time.
So, other things to think about here would be your back end, you know, where are you hosting your infrastructure?
So like Aws or Azure, you know, is that created on your account?
Right?
Are they working off of your account?
It’s pretty common if you’re working with an external partner, they’ll create some sort of a sandbox or an environment that’s on their account and then you gotta worry about migrating that stuff and that you don’t have control over that later.
So How confident are you right now that you control all of your product artifacts?
1-10 and it’s got some notes on there.
I’m not sure about this.
So account for that in your grade.
question# seven.
What is your next validation gate?
How confident are you that you’ll hit it on time and budget with sufficient insight to move on.
So, first off, what is a validation gate?
This is sort of a AAA term that I use to refer to knowing and being clear on what is the next sort of checkpoint that we’re trying to get to where we’re gonna get some kind of validation that’s gonna, allow us to go to the next step.
Right.
So I’m, I’m a big fan of trying to chop up a product development effort, whether it’s again launching an initial product or ongoing stuff, what is the next validation gate that I’m, I’m getting to?
How am I gonna measure it?
Right.
So we need to be clear on what does success look like?
How, how will we measure it when we get there and then what would we do next once we, you know, we, we validate it, right?
If we get like the good validation, what’s our next step?
If we don’t get the validation?
What are, what is our plan for that?
So how clear are you on what’s next for product road map?
rates off 1 to 10?
And the final question here is how confident are you in your minimum viable analytics or M B A s as we call it?
How sure are you that you’re meeting them or that you’re going to meet them?
So first part of this question is, do you even know what your M B A s are?
What are your key metrics that are important to get a read on that, determine whether your product is successful or not, right?
If you don’t have any NBA S to find like you need to, you need to go with a low score here and you need to immediately figure out like, what are those metrics?
What do I need to measure?
How do I know if I’m being successful or not?
And these are real analytics, these are not just vibes, right?
So this is stuff that you can measure at a minimum and you need to be looking at it regularly.
And so how clear are you that you have NBA S that you can measure M B A s and that you have the right NBA S, right?
So again, score of 1 to 10 on this one and we’re gonna move on to sort of like our, how we tally up like sort of our final score.
So we want you to add up your score across those eight questions and this is pretty straightforward, right?
If you’re in that 65 to 80 point range, that’s kind of an A plus.
It’s exceptional.
You’re probably in pretty good shape.
55-64, we would call that solid or maybe pass.
I would still shore that up.
D needs improvement.
D is dangerous territory.
The below 24 points, we’re given it an F it’s time to rethink everything.
This is pause territory, this is pause, everything and let me figure out what to prioritize on shoring up before we continue to, to put time and resources and money towards this.
So, add yours up, figure out where you land and, you know, if, if, if you need some assistance on sort of how do you shore these up?
That’s certainly something that, that we, we can help with or, you know, feel free to reach out.
We’ll give you any input, we can.
I’ll pause here for a second to see if we had any questions come in, Jordan.
I know you’re on here as, as a moderator helping me out.
Is there any questions that came up that maybe before we did today’s webinar or something that, that came up during that maybe I should talk about?
Yes.
I just put them in the chat if that helps.
Actually, I can’t see it from my screen view.
So would you mind just reading it out?
I’ll just address it that way.
OK.
How early on in the process should validation gates be identified?
And can they be implemented if the build is already underway?
Good question.
So the earlier, the better, I think you should have your M B A S defined before you even start developing something, right?
That should be in this sort of vision slash clarity phase where you’re nailing down the big questions that, that, you know, nailing down the big answers to questions that are really important.
So usually in that bucket, it’s the things like NBA s, right?
Because it’s tied to success.
Like you, you, you should never start building a product before.
You’re really clear on what does success look like?
I need to be able to define success before I even know whether it showed up on my doorstep or not.
Right?
So NBA should be like very early on before you’re developing.
But, but while we’re on that topic, other things that I think should be included would be a lot of things we talked about in this deck actually, right?
How, how clear and confident are you in your architecture or your technical approach?
That’s super important.
How clear are you on the product vision which very, very often mirrors like, like clarity around your user experience, right?
Because if you’re really clear on the user experience, a lot of times along with that comes a lot of alignment with stakeholders, right?
So those are other things that you should be really clear on, have a great plan, super buttoned up on that before you start, like, like actually developing the software.
And I think the other part of that question, Jordan, if I heard you right was can can you, can you come up with the NBA S or is it too late to do it when you’re already in development?
And I’d say no, if you don’t have them, you need to make it a priority to do them.
Now, even if you’re in development, you need to backtrack and figure out what are we trying to, to achieve here?
What is success for us?
And then how do I measure that?
And that’s a great sort of way along that line to, to step in, to figuring out what your NBA s are, is start with, we’re building something.
What is success if we launch this and then we’re looking back kind of assessing it like, what would we look at in order to know whether it was successful or not?
And then when you start answering those and start figuring out.
Ok, well, well, what are the metrics or measures that can be tied to those success criteria?
And that usually will help land you pretty close to what your M B A should be and you’ll build those over time, right?
Cool.
Good question.
Was there any other ones that came in?
, no, not yet.
These are the only ones I have so far?
Ok.
Good.
I’ll, if, if, if somebody else has a question, go ahead and throw it in the, the Q and A, window and we’ll go look at that, in the meantime, I’ll give it a few more minutes.
But, if you guys have questions, you know, on this topic or other topics that we talk about, feel free to email us at info at N 08 dot com.
That’s E N 08 dot com or I’m pretty active on linkedin.
There’s my link.
You can find me on linkedin, feel free to send me a direct message there and I, I try to keep up with those pretty well.
And so if you’re, if you’re on a AAA product development effort and, and you have questions or there’s something that you just like some input on.
We love hearing those.
How we come up with a lot of our ideas for, for these N 08 answer sessions.
So if you have questions, please reach out also too, if you have topics that come up a lot and you’d like to hear us do one of these on it, always looking for great topics that people are really interested in.
So, you know, feel free to, to share those topics with us and we’ll get that in the mix and maybe do an N 08 answers on some of those topics that come in.
You know, one other note here, You know, we do, we have a one of our offerings that, that we’re really proud of is, is called our Inno Innovation Lab.
It’s where we really address a lot of the things that we talked about in this deck.
But we do it up front and we’ve got a really great process for it.
So it’s efficient, it’s fast.
We we really get answers to a lot of the really big questions to get you set up for success.
So the Innovation Lab is all about really reducing the, the risk associated building new products.
And, you know, just setting you up to really better hit the business target or what you’re building.
So we’ve got a terrific process.
If you want some more information, you can check out our website.
It’s dot com slash innovation dash lab, check that out and there’s some good info out there on that.
Let us know if that’s something you’d, you’d like some more information on or that we might, could be assistance on and then, you know, while you’re out there, you know, check out subscribing to our newsletter or just, just sending us a note through one of our contact forms.
We’ve got a great weekly email.
It’s not a big fancy marketing email.
We just basically pick a topic every week and then, and I write like a, a plain text, like narrative on, on one of these topics that comes up a lot.
I think it adds a lot of value for people in this product space.
So it’s aimed at like product owners, founders, executives that are overseeing product development efforts, sort of anybody involved with like sort of leading, you know, launching new digital products and digital innovation.
So I think there’s a lot of good information that you can get signed up for and of course we have a newsletter that goes out every month that has good info in there too.
So, check that out.
on that.
I don’t think there’s, if there’s no other questions come in, I think that’s, that’s all for today’s session.
I appreciate you guys checking out the, the recording and again, let us know if there’s other topics that you think might be of interest that we could tackle in the future.
we’ll, we’ll see you next time.
Thanks a bunch.
