Hey, everyone. Thanks for joining us today!
This kind of a new exciting small little info session that we’ve started doing called ENO8 Answers.
So thanks for joining us today.
We’re kind of excited to talk about the topic that we have, we have planned for the discussion day.
Before we jump in, I kinda wanna encourage you all to feel free to drop questions into the, the question chat and I’ll try to feel those as we’re going through this.
We don’t necessarily need to wait all the way until the end.
But yeah, so feel free to drop those in and I’ll try to keep an eye out for them.
So just getting started just a little bit of quick background about me.
My name is Jeff Francis.
I’m one of the co founders of ENO8.
We’re a inc 5000 Digital Innovation studio based here in Dallas, Texas.
And you know, me personally, I’ve, I’ve done a lot of work with companies of all different sizes.
you know, in particular, a lot of different startups or new product development within larger organizations.
I’ve probably helped over 100 startups over the last last decade or so, in identifying planning, designing, building and then launching all kinds of different digital products, mobile applications platforms.
you name it.
And so, you know, what we had planned on talking about today is an area that we get a lot of different questions about pretty frequently.
Those folks that aren’t around building custom software, a lot don’t really understand a lot of the different approaches that you can take for configuring teams.
And so one of the big questions that we will very frequently get is, should I work with an all onshore or us based team or should I find an offshore team, you know, in India or maybe in Europe somewhere?
South America, should I find a, a AAA group that’s lower cost?
What’s the right fit for me?
And so, you’ll get the classic kind of consulting answer from me in, in, in that it depends.
And I think one of the big things to really stress is that, what is the right fit for you is not a one size fits all type of decision.
a good part of it.
In fact, I think the majority part of it depends on, you know, where you are with the product, right?
The think of it as the product life cycle.
And so what I did was I kind of divided these into really broad simple buckets.
So just a little bit of a disclaimer here.
This is a very simplistic view at this.
There’s a lot of different nuances and complexities that can come into play.
But what I wanted to do is get a little bit of a general idea and general guidance.
And then if you guys have questions, feel free to throw those in and I can kind of drill into different elements of this.
But what I thought would be good for the purposes of today’s no eight answers session would be let’s give kind of a broad view on it and then we can dig into some of the details and if you guys have some some questions on that.
So at a high level, I kind of think about dividing the product life cycle into sort of three main buckets.
One is sort of the upfront what I would refer to as like the vision or design or sort of creative planning stage, right?
Think of this as where you’re kind of considering like should I build this product or should our organization build this product?
What’s the vision for it?
What’s, what’s the compelling problem that it solved?
Why is it going to be lovable by users?
What’s the business impact?
How will we measure that?
Right.
And then it goes a little bit further once you got a little bit of validation and well, what exactly is it going to do?
What’s it going to look like, what kind of technology are we going to use to build it?
Right.
You’re sort of answering a lot of these like real big questions and then you can go even further to the details, like what’s the architecture, right?
Like, like what kind of team do I need to execute on building this?
Right?
And how big of an effort is it, how much of it should I try to fit into sort of an initial launch like an M V P or a V one?
Right?
So think of this stage is like the very high creativity, high unknowns.
This is where I think a lot of the most significant innovative sort of thoughts get flushed out.
So, so this is sort of stage one right?
Next stage would be, you know, really sort of executing on what you created in that vision stage.
So I call it like the V one development stage.
A lot of people call it M V P at N 08.
We, we don’t like mvps, we call it the M LP, the minimum lovable product.
I can talk a little bit more about that later.
But V one or the MLP development is really kind of like what is your first version of your product that you’re going to get in hands of users, which is a really important stage, right?
And then if that goes well and you’ve done things right?
You’ve got something that’s valuable to users, you’re getting adoption and it’s actually solving the problems that you thought that it would, then you could potentially move into like a third stage, which is really more of ongoing product development.
One of the things that I see software entrepreneurs commonly make as a mistake is they have this perception that I need to build this software and then when I launch it, then I’m sort of done, right?
But the important thing to understand is that if you build a software part that is successful, you are now a software company.
And so you’re going to have to continue developing it.
Ongoing development will never go away.
In fact, It’s going to increase massively according to how much success you have, right?
So three main stages, sort of a vision concept, innovation, stage building your initial product, like the MVP or the V1 and then going into ongoing product development, right?
And so what, what, how this relates to what kind of a team, whether it be onshore or offshore or both really relates to which of these stages you’re in.
So let’s start with the stage one.
This is where you’re, you’re trying to flush out the details of the vision, what exactly we’re going to build, what are the core features?
What’s the most compelling lovable elements of this product that we think will make it compelling for users, right?
And you’re, and you’re making sort of big high level decisions.
So think of it as high level decisions on, you know, what’s the really the target persona for this, what’s their journey and how do we fit into that?
What’s the technology that we’re gonna use?
What’s the stack that we’re gonna utilize?
Right?
A lot of these real big key decisions will impact this product for a very long time.
And so it’s really important that you really get that right?
And so generally speaking, I I tend to to, to instruct our clients that that upfront phase is really best if that’s a pure on onshore team, if you can do that, right?
So and most of our clients are in the US.
So when I say on, I’m talking about like in the US, so People that might be involved with that during Phase one from an on an onshore team could be, you know, who’s the product owner, this could be the visionary, be the entrepreneur or the product owner with an organization, who’s the one ultimately that owns the vision of this product, they have to be super involved, right?
Key stakeholders from the from the product team, like if there’s, if there’s other executives that are gonna be involved with this, if it’s a start up or if there’s other key department heads, if this is a product that you’re building for an existing organization, they would need to be involved with that, right?
In terms of the the product team itself though.
you, you probably want a solutions architect.
This is someone who’s gonna be looking at this through the lens of more of the technology.
a design strategist is a great imperative person to have involved in this stage of it because they’re really focused on the product itself and the user experience.
So, and that’s, and, and, and, and some people get confused between user experience and U I.
When I say user experience, it’s really talking about the entire experience of a user going through the journey and interacting with this product, right?
Not just what does it look like.
And so having a design strategist, a solutions architect and you know, potentially a project manager involved with this stage of it along with the product owner and key stakeholders, that’s gonna be the core of what you want to have.
So I would highly recommend that those type of folks be part of an onshore team that’s working on this, right?
And so there’s a lot of high collaboration, a lot of figuring out the answer to the really big questions and if, if done, right, this is a really creative part of the process.
So you’re really trying to keep open minded about things and explore what’s possible and think about like how can you do something that’s gonna be really impactful, right?
So high creativity, high unknowns, then you generally want to be, you know, in sort of an onshore team configuration.
So then let’s say that you go through that phase, right?
You’ve nailed down the details of what you’re going to build.
You’ve got a good idea on the technology, you’re gonna use your technical approach, architecture, even the design has been nailed down.
Then you’re gonna move into more of like a V one development phase.
And so in an ideal world, you would also want to do this onshore, but if planned correctly and you do that stage one, well, you can be pretty effective in actually blending a team of onshore resources and offshore resources to do this V ONE development.
And so what we found is that the folks that are on that stage one team, you know, we, we call it our innovation lab.
That’s where we do a lot of that kind of work.
Those folks, a couple of those roles stay engaged in the development during V one.
So for instance, that design strategist and that solutions architect would stay involved with the project, right?
And that creates a lot of continuity.
And if you have those people who are involved in the early planning and design, then you have the ability to utilize some offshore resources as part of the development team, if not doing a majority of the development team.
And so as we talk about that, like one of the things I I like to specify here.
Is that what I’m talking about mostly in these scenarios is these are development teams that are, you know, five up to 10 people.
If you get bigger than that, then my advice would probably change a little bit, right.
It gets into more, more kind of a scaled agile approach and we could talk about that a little bit if anybody on the call has questions about it, but back to one.
So when we’re building D1, we see a lot of success by having a blended team, some onshore, a good part of it offshore.
And when I say offshore, I’m talking about true offshore that would be more like like, you know, India, maybe certain parts of Asia.
But we do a lot of work with India resources and had a lot of success with that.
So in V1, you want to have that continuity where you have the solution architect, the design strategist, which more of your UX person, potentially, even a designer that stays on as part of the product team.
And then you have development and testing primarily from your offshore team if you’re able to make it work.
Having a lead developer on the onshore team working with other developers offshore is a really great configuration too.
But sometimes because of budget reasons or whatever that, that’s sometimes difficult to, for a client to make happen.
So it’s super important that your solution architect is involved at the code level, actually helping a review and make sure that the development work that’s getting done during V One development is following the architecture plans that were created during the vision phase, right?
And so that V One development, I would generally say a blended model is OK there, right?
Stage three or that that that third phase that we talk about is when you start shifting into ongoing product development.
So what does that mean?
So this is normally the part of the process where we have, we’ve done all the design work.
We’ve built an MVP, we’ve launched the MVP.
We’ve gotten good validation, we’ve hit our targets that we were looking for in terms of judging success of the product.
And so now we’re shifting into ongoing and iterative improvements and enhancements, right?
So at this stage, there’s, there’s perhaps less big innovation, not saying you can’t innovate along the way, but it’s a little bit more iterative in nature than maybe in the vision phase.
And You’re, you’re settling into more of a process, right?
So you’re getting into a routine and a rhythm I I if you’re planning correctly and you’re, you’re managing your resources.
Well, a lot of the resources that were involved with the V1 development perhaps are gonna stay on as part of that ongoing product team.
And so in this scenario, you can start to shift very heavily if not all the way to offshore team provided a couple of things, one is you have to have a very engaged product manager.
And so if we’re talking about where there’s a,, a main team that is in the US, that product owner has to know what’s going on with the team.
And they have to have some sophistication and comfort with managing offshore teams.
Right.
And I can talk about some tips and stuff on that in just a moment.
But they have to be participating if possible in like daily stand ups at a minimum.
They have to be approving sprints and they have to be doing sprint demos, right?
So they really have to be plugged in.
You can’t throw stuff over the fence and expect the team to meet the expectations, right.
So there’s some process stuff and some sets that we’ll talk about in a second that’ll kind of help improve that.
But that team over there could consist of, a Scrum Master which would be sort of a project manager.
They’re responsible for running the ceremonies, planning the sprints, managing the work by the team, making sure they’re on track.
escalating if there’s any issues that come up, perhaps something’s taking more effort than originally thought they’re managing timelines, they’re managing releases.
So that Scrum Master could be part of an offshore team, the developers could be offshore and Q A could be offshore as well.
definitely the product owner has to be onshore.
And then like I said in like earlier in phase two or stage two, it would be nice if you also have someone technical or someone who’s involved at the code level, like a lead DEV or maybe an architect that does a little bit of coding code review, that kind of thing involved even in that ongoing product developer, right?
So if we kind of summarize, you know, that phase one vision phase, ideally all onshore team M V P or B one development, that could be a blended team, ongoing product development, it can be an all offshore team if you have a process and comfort level and you know, some experience managing an offshore team provided that that product owner is here, right?
So let’s talk a little bit about, you know, when you do work with offshore teams, what are some of the common pitfalls?
What are some of the tips that I could potentially give you just based on our experience that that really help make that option run really smooth, right?
But before I get into that, one of the things I want to point out is that a lot of times people lock on to what’s the cost comparison cost of an onshore like us team or resources versus offshore?
And it’s very alluring, right?
Because there is a significant cost difference.
but but don’t be fooled into thinking that it’s, it’s, it’s straight up that difference in cost, right?
There are trade offs sometimes, right?
And you just need to plan for those to make sure that you fully capture the benefits of whichever the model that you go for.
And so if you’re gonna go with AAA pretty heavy allocation with an offshore team, a couple of things that you really want to keep in mind, one is you gotta make sure you have some pretty fundamental established processes in place.
We, we, we follow agile, so we’re really more of AAA Scrum team and so some of the basics there that are really important is making sure that you have your ceremonies in place and you really stay committed to sticking to those, right?
So, so, sorry, I just check my notes here.
So, what you want to make sure you do is that you’ve got the ceremonies locked into place and they’re on a recurring schedule.
So you don’t want to have to add hot schedule, things like sprint, demos, sprint playing, things like that because you’re constantly coordinating schedules, set that stuff on a recurring schedule, make sure that you’re sticking to it.
So some of the basics would be daily stand up this one.
It’s a must have, you have to, to have a daily check in even if it’s just 10 minutes on.
What did you guys work on yesterday?
What are you working on today?
Are you blocked on anything.
And so by doing that, you can help make sure that the team stays on track and that you, you have a good pulse of progress and where we are within the sprint.
The next one is, you know, having a AAA prop for sprint planning so that, you know exactly what you’re planning to go into the sprint, right?
And you have that defined sprint box and stay consistent with those one mistake that I see a lot is that people will stretch sprint because they’re almost done.
They have a couple more items so they’ll extend sprint a few days.
If you do that, you can’t ever really get a really great idea of velocity for your team and it makes it really hard to plan.
So, have a proper sprint planning.
The product owner needs to sign off on that sprint plan before the team starts on it and then you need to have it scheduled for the team doing their sprint showcase or their sprint demo at the conclusion of that sprint.
And so this is aimed primarily at the product owner.
So the product owner is able to review.
Ok.
So what we planned in the sprint now we’re reviewing where we landed.
Did we get everything done?
And let’s actually see working software, right?
So those sound really basic, but you’d be surprised how many times people because they’re short on time or everybody gets busy they’ll start cutting little steps out of the process.
Well, we’re not going to do the sprint demo this time because I already kind of know what’s going on.
Don’t do that.
Make sure you do the demo.
Right.
another byproduct of the demo that’s really important is the teams probably worked really hard on what they’ve been, doing in that sprint and it’s their opportunity to sort of show off their work, right?
And everybody likes to be able to show the results of their hard work and effort.
So I think that’s really important just to keep the team motivated for nothing else.
So, a lot of these ceremonies is really about, you know, making the communication really smooth, right?
And that’s one of the big challenges of managing an offshore team that’s in largely an opposite time zone, right?
So the daily stand up is a point on the calendar every day.
We know we’re gonna sync up, right?
So that’s a big step of it.
Other things that we utilize that kind of help facilitate communication is you know, some sort of asynchronous sort of chatting tool, like, like Slack, like we use Slack at N O A.
It works really great for us.
We actually, when we work with clients, most of the time, we actually have them on a Slack channel where we can collaborate together with their whole team.
And what I like about Slack as part of a AAA product team.
Communication is unlike email, certain people may not be on certain email threads and stuff.
But Slack is sort of like, I think of it as almost like a project Town Square where you can see the conversation going on.
Sometimes that conversation may not pertain to you in particular, but you see the conversation so you pick up a lot of things just from sort of observing it also too, if you see a conversation going on and it’s getting on the, on the wrong track or it’s, it’s not clear, it’s easy for you to jump in and be part of that conversation and get back out of it again when you’re no longer needed.
So, Slack is a great tool to help kind of collaborate on that.
I would encourage people to keep the conversations in the project channel, avoid little one off direct messages on different topics because you lose that benefit of everybody sort of talking in sort of a, a group environment.
So communication is super important.
Sticking to ceremonies is super important.
If you do not have somebody on your team that is very experienced working with an offshore team, I would really recommend finding someone to help you with that, right.
Either a company that has a lot of experience doing that as part of their way of delivering or even if it’s just somebody that you have on your team full time or part time, but they have to have a lot of experience working with that because you’re gonna save yourself a lot of mistakes and a lot of waste of money, a lot of waste of time.
So, I think I saw a few questions come in.
I’m gonna go take a look at these.
, let’s see.
I had a question here.
Actually let me think.
we talked about onshore offshore and what roles talked about some pro tips.
So we’ll just jump into Q and A.
All right.
So first question I hear here is, can a software development company help me with the first stage or does that have to be in house?
It sort of depends on who’s on your team, right?
I find that that upfront phase requires very niche, very specialized, very experienced resources that you need in a heavy dose in that first stage, but you may not be need, you may not need them ongoing in enough quantity that makes sense to have that person on your full time team.
So as an example, a design strategist, this is typically a person with a heavy U I U X background.
A lot of times sometimes they can come from a technical background but they’re heavy U X, heavy U I design thinking is a really common approach for sort of working that through that, that upfront process.
and those people are, are the ones that are really good.
They’ve worked on a lot of different products.
So they’ve got a lot of experience and a lot of background to sort of pull from in that, that can be really valuable.
But once you get to that design phase, it may be hard to keep them fully utilized and, and leveraging what they’re really great at and what they love doing on an ongoing basis.
So because of that reason, I tend to think that that finding a partner or, you know, even someone on a temporary basis that can kind of help with those upfront design elements is, is really like a good approach.
It’s actually the phase that I think in a way we, we’re really probably most unique at and that we’re really focused on that upfront, bringing clarity the and getting, getting getting all the big answers to questions that that will plague software projects in the future, really getting that stuff flushed out up front.
So we call it our N 08 Innovation lab and we’ll typically have a design strategist, a U I designer solutions architect, a project manager, maybe a product strategist involved with that upfront planning phase.
So if you’re interested to talk more about like kind of how we do that and what we do with our clients, then then reach out to me.
I mean, I, I enjoyed talking to you about that part of it.
Let’s see, jumping to the next question, is there a point where someone is too far into a project life cycle to switch onshore, indoor offshore roles?
I don’t think so.
I think, I think the most important part on that question is being honest with yourself.
Right.
One of the, the big challenge is that people, people suffer from sort of the, the sunk cost fallacy, right?
Like I’ve already got so much sunk into making this work or invested with that person, it’s just not working, but maybe if I can just get to next week or this next deliverable and it’ll start to work.
And so I think being really honest with yourself about it is this working?
Is this accomplishing my goals?
If not, I need to make it page, right?
Not necessarily personnel.
Sometimes it’s just communication, we need to get on the same page and refine some processes.
But I think being honest about is this model working for us and where are we experiencing issues is a good place to start?
That’s where the experience comes in.
So making sure that you have somebody on your team or you have a partner that really knows how to do this.
So they can quickly identify where these gaps are.
What can we do to adjust along the way.
You know, if we think about like let’s take a startup software company as an example and then going through those stages, I’m gonna put back that slide.
So if we, if we think back about the three stages, a very generic life cycle of a startup company, getting going and building their product and then building their team along the way would look something like this.
They may work with a partner like N 08 to do stage one, right?
We help them get clarity, we help them verify they actually want to build this.
We we help them understand how they’re gonna build it, what it’s gonna look like and all the technical like big pieces of it.
And then we move on to the M V P development.
At this point, it’s very common for the startup to still not really have a development team.
So they’re relying on a third party kind of like N O A, right?
But once they get validation and they move into that ongoing product development, then a common question I get is when do I start hiring my own people?
Right.
How long do I work with a partner versus bringing it in house?
This is a really good question.
Generally speaking, one of the first roles that I encourage people to hire in house is actually the product manager, right?
Oftentimes people will go towards I need to hire a CTO or I need to hire a solution architect or need to hire a head developer or a lead developer, sometimes those can be the right fit.
But I would say that more often than not having someone who’s gonna be the main product owner being plugged in does a couple of things.
It’s a really good move.
One is they can they, they really bring the expertise on the product and the user on your in house team, which is really important.
They’re gonna drive that vision and it really puts you in a situation of what I call being vendor agnostic, which means that you have flexibility to switch partners if you need to, right?
Or if you just feel like that, that something’s not working.
And so you have that product expertise in house, they understand the product, they understand the road map and they can much more easily take that knowledge from one team to another, right?
The other part of it is that they can help with other parts that are important to an early software startup from the business side.
So this could be working with the sales team, you know, participating in sales calls with the prospective customers because they are the product expert.
And then also being that close to the sales team and the end users, they oftentimes get a lot of good insights, they can then turn around and convert into new features and development work that gets sent to the team, right?
So they can help on the business side, they could be the interface with the development team, they can also help with the executives and understanding just where we are generally with the product, right?
So they’re more high level.
I think people go towards the CTO stuff a lot of times because they think that they need that technical person in house.
My experience with hiring a CTO or an architect really early on maybe is like your first in house hire.
Again, we’re talking about experience specialized resources and most of those folks, they really like that, that creative process.
So unless they’re doing a whole lot of that work, sometimes it gets hard to retain those types of employees on your in house team, right?
So let’s just make sure we’re using the right tool for the right job at the right point in the life cycle.
So you could start with hiring a product manager and then maybe after that, you would add maybe a developer or a lead developer and then continue to, to sort of work collaboratively with your partner.
So what we’ll do a lot of times is as our clients grow and they gain more capabilities in house, then the type of team that we have configured in that stage of the product changes over time.
So maybe it starts off with everybody involved with it as our team, except for maybe the, the executive sponsor or the product owner, right?
But as we progress over time, they build more of a team in house and they can augment using our team because it’s more flexible, right?
So if they hire, you know, a lead developer, then maybe they add another Q A to our team, they take off a lead developer or they just grow the team, right?
So that’s kind of how I would split those up.
But let’s see here.
We got a new question.
there a point where someone is too far in a switch.
Ok, got it.
What’s near shore?
How and when can I use it?
near shore is a term.
It’s funny I haven’t heard near shore as much over the last couple of years as, as I did before.
I’m wondering if some of that may be related to COVID or not, but because more people are working remotely and the lines have gotten blurred.
But near shore, generally speaking is when you’re talking about using resources from neighboring countries or countries that are in a similar time zone.
So in the US, for instance, if you had maybe resources that were in, say like Mexico or Brazil or Costa Rica or something like that, that would be considered near shore, right?
So they’re not in the US.
But they are in a similar time zone.
And so, you know, think of near shore as sort of lying somewhere between all onshore or offshore, right?
So from a cost standpoint, they’re gonna be a little bit in the middle.
And the benefits are gonna be a little bit in the middle, right, may not be as ideal as having an all, you know, us based team necessarily if you’re a US based company.
but there’s a lot of benefits over, you know, an all offshore team because they’re in that same time zone and some of those barriers to communication and moving things faster, can be a little bit easier with an air shore team.
one way that near shore comes into play a lot of times with our clients is when they get into that stage, if they launch their V1, and they’re really kind of shifting into that sort of third phase where they’re doing ongoing product development.
Now that you’ve got live users on your system, you have to think about things like how do I do live production support?
Like for instance, there’s an issue in our production environment during the middle of the afternoon, oftentimes the, the offshore team is already off line for the day unless you’ve got some kind of special arrangement there.
So what I’ve seen sometimes our clients will do is we’ll work with them to have a near shore resource that is also on the team.
So they get a little bit broader coverage.
So they’ve got the coverage or morning time from the offshore team and then moving into the afternoon time, they still have a near short coverage right to get them through the rest of the business day in case there’s any issues that need to be addressed.
And they still have some of that cost benefit of a near shore resource versus an all onshore resource.
So there’s some creative ways where you gotta start thinking about.
Once you got live users on this, you have to plan and be responsive to any issues because now it’s in a production type of environment, right?
Let’s see here.
I think that’s, I think it’s all a question.
We’re getting a little bit over time here.
So I’ll kind of wrap up here.
I hope you guys found this valuable.
If you if you have other topics or other questions, we’re gonna start doing this on a pretty regular basis, maybe even like weekly.
And so we’re kind of referring to as N 08 answers.
We’re trying to identify those types of questions that come up a lot with conversations with our clients and potential customers.
And so, we just want to add a little bit of value and share some of the things that we’ve learned along the way and, and hope that it helps you guys in your pursuit of bringing some sort of digital product to life.
I’ve got my information up on the slide there.
Feel free to reach out to me on linkedin through direct message or you can check out our website and submit a form through the contact page or even drop an email here at info at N 08 dot com.
I really appreciate you guys check out the video today.
I hope this helps.
Please reach out if there’s anything that we can ever do to help.
Thanks so much.
