Protecting Your Customer's ROI
A core business belief of Bixly's is this: our customer's success is our success. Here are a few ways we protect our customer's ROI because we believe in partnering with them on their goals.
Full Transcript Below:
Cris:
How can you improve your return on your investment?
Andrew:
But we'll identify kind of, what are the major risks, what are minor risks and sort of everything in the middle too. The project might be done in October, or it might be done in November if some of these risks manifest.
Cris:
How does that help you get a return on your investment?
Cris:
We are going to talk about improving ROI on your project, and basically what are some of the things that we've obviously found to be very handy over the years on all the projects we've worked on. And really anyone that obviously wants to work with us, this is useful, gives us some backstory of how we like to do projects, but also, even if you're just looking for a freelancer or thinking through your project, how can you improve your return on your investment? So I think number one, it seems obvious, but you need to identify your risks. So let's unpack that a little bit. As a project manager, how do you work with clients to obviously help them identify their risks and kind of prioritize things, I guess, in a way?
Andrew:
Yeah, that's a good one. So the risks usually come from uncertainty, right?
Cris:
Okay.
Andrew:
The unknown things and much of the unknown comes when you're dealing with third parties.
Cris:
Okay.
Andrew:
So let's say a third party would be Apple. We're releasing an app to support iOS. We don't really know if in the middle of the project, if a new version of iOS is going to come out, if it's going to break the work that we've done.
Cris:
Okay.
Andrew:
Things like that. So we can identify risks like that, but you can't necessarily scope them. We just have to, or you can't necessarily estimate them. Right. You just have to identify that they might be there. Or maybe the client will say, we want to work with this ticket printer but they don't necessarily want to take the time as part of roadmapping to like, do a proof of concept, print out tickets. Maybe they don't have the ticket printers yet. They're going to order them after the fact.
Cris:
Okay.
Andrew:
So we have to make some assumptions about like, well, this one seems like it's not going to be overly complicated to deal with. If there is, we need to kind of allow margin for that, but we'll identify kind of what are the major risks, what are minor risks and sort of everything in the middle too.
Cris:
Gotcha. And so by identifying this stuff and almost kind of like aligning time of how long it's going to take. How does that help you get a return on your investment? I mean, seems obvious, but like, how does that actually help you if you're like, I'm prioritizing things, I'm identifying these risks, like how does that help you on your investment?
Andrew:
It allows you to plan.
Cris:
Okay.
Andrew:
Right. Both financially and timeframe wise. Right. So the project might be done in October, or it might be done in November if some of these risks manifest.
Cris:
Okay.
Andrew:
And so that way you're not communicating to all of your customers or shareholders that this thing will definitely be out October 1st, because maybe it will, or maybe it won't, depending on the risks that are involved.
Cris:
Yeah. And even being able to, I'm guessing kind of prioritize things at some point, which we'll talk about later, but if you prioritize those things a little bit, you can even decide, should I tackle this right now or should I not based on the risks of it essentially.
Andrew:
Right.
Cris:
And how long it could take.
Andrew:
Could this break my system? Yeah. All different stuff.
Cris:
Cool. Obviously we like to communicate throughout projects. I think constant communication is a very important aspect of having a good return on your investment. The longer you take to communicate a problem to someone, the more time goes by without that problem being fixed. And then that costs money.
Andrew:
Right.
Cris:
Obviously, because as we've said, time is money. How do you like to kind of work with the customers and ensure that there's constant communication happening and that it's not something that just happens at the beginning and then disappears like throughout the project?
Andrew:
Right. Right. Well oftentimes we're doing iterations every two weeks.
Cris:
Yeah.
Andrew:
We're planning the next sprint out with the client. Oftentimes it's two weeks. So we'll have meetings at least every two weeks with the client to review the progress, to gather any feedback. And then oftentimes we use Slack if the client likes to use some kind of a chat program. And so even in between those iterations, there's communication of things going up there, potential screenshots, stuff like that, getting feedback. A big thing of it is how do we communicate? How do we get feedback beyond just kind of laying out the initial plan. Right. And then we also have very consistent communication with our developers, usually on a daily basis to make sure that what they're doing is aligning with what the product owner wanted, it's matching the priorities for this brand. So client communication is a little less frequent. Developer communication is very frequent.
Cris:
Yeah. And I'm assuming the whole time we're trying to continue identifying new risks that are coming up. We're communicating that back to our team. We're ensuring that we're working on the most important things and that in turn is saving money potentially.
Andrew:
Right.
Cris:
And hoping your investments work well. How do we, or I should say, how do you kind of handle planning future stuff like resource wise? Is that a good return on investment to like think ahead to the next things that need to be done and who needs to work on them? Like how does that help?
Andrew:
It's certainly helpful to, I mean, planning that could mean a lot of things.
Cris:
Yeah.
Andrew:
But I mean, in some cases there's things that are very predictable, like an SSL certificate's going to expire. Right. And so we can plan that with our DevOps team, we can plan to do a security audit. If the client wants us to audit the system every six months or use like an error reporting tool, we can kind of plan around that stuff. Or there's really just planning in terms of maybe this is the client's vision for the project. And we know that in the first two releases, this is what they want to do, but then there's kind of this cloud of release, three, four, five out there. And so by understanding their vision, it allows us to kind of make sure that we're moving in a direction that's consistent with that and not pigeonholing anything. So we plan by understanding both the technical aspects and also just what's the client's long term vision for the project.
Cris:
Gotcha. And then from there we plan the resources out. So if those first couple phases are going to be very design heavy, we're ensuring that the resources, or if you're looking to do a project, not with us, but with a team and you know the first two phases are going to be design heavy, you should plan for some design resources, people that have a design's eye because that's what you're going to be focusing on for the first couple months, sprints, whatever it is. And then you know well we have to do the SSL. So I got to know someone has to have some DevOps experience. And so it's the whole idea of taking tasks and aligning it with the practical, like physical boots on the ground people, the resources that are going to do it. Because if you show up and you say, let's go and they're like, I don't have someone ready to do that, that's obviously costly.
Andrew:
Yeah. Certainly we have to plan to have people that can do the skill set that's needed.
Cris:
That's good.
Andrew:
Yeah.
Cris:
I feel like we touched on kind of the next item I was going to say, which is feature prioritization. We touched on that one a lot already. Anything else to add to prioritizing features without feeling redundant?
Andrew:
Yeah. I mean feature prioritization is really important for ROI. So as we're going through, I would say usually road mapping, we're helping the client identify, okay, this is a high value feature. Really they help us identify these are the high value features, these are kind of medium, these are low. And then they rely on us to let them know the complexity of implementing those features.
Cris:
Okay.
Andrew:
So if something say like high value, but low cost, that's a really good candidate to prioritize force.
Cris:
Okay.
Andrew:
And then after that comes the high value, high cost items. And obviously we're trying to stay away from the low value high cost items.
Cris:
Right.
Andrew:
But to the client, it may seem like, oh, this is like something that'd be kind of cool. It's not real valuable, but they don't realize that it's going to take six weeks to do.
Cris:
Got it.
Andrew:
And so it's our job to help them identify that. And ultimately come up with a prioritized list of, in the first release, this is what it consists of, in the second release this is what it consists of. And there's their plan for the life cycle or their project.
Cris:
Good. You mentioned obviously sprints and do we generally, do seven, eight sprints and then do a release? Do we release after every sprint? Like what's a good return on your investment?
Andrew:
Yeah.
Cris:
How should you be doing your releases?
Andrew:
I mean, it depends on the nature of the project. We have some projects where we're like, staff augmentation projects where we're working with a client 40, 80 hours a week just on a regular basis, like we're their development team. Those, I mean we'll sometimes release every couple weeks or so.
Cris:
Okay.
Andrew:
If it's more of like we're building a product from the ground up kind of thing, I would say releasing anywhere from every like one to three months is appropriate.
Cris:
Okay.
Andrew:
So we're doing the two week iterations and delivering value in those iterations, but realistically only releasing somewhere between every one to three months.
Cris:
And it, I mean, it's really just the fact that you're establishing a regular release schedule of some sort and people are adhering to it. And again, you're just playing back into consistent communication, identifying our risks along the way and ensuring that we have something as a litmus to kind of like test against.
Andrew:
Yeah.
Cris:
And say, yeah, we're still on track.
Andrew:
Right. And again, it depends. It's kind of nuanced. I mean, some projects are very feature locked where we're going to release after this set of features is done.
Cris:
Right.
Andrew:
So it's not an amount of a period of time. It's after these features are done, we release.
Cris:
Sure.
Andrew:
Others are time locked where we're going to release after this period of time.
Cris:
Got it.
Andrew:
Features that didn't get done will need to go in a subsequent release. So it's really up to the client. Do they want to fix the feature set or do they want to fix the timeframe? Trying to fix both is very difficult and just hard to predict.
Cris:
Yeah. But ultimately it plays back to everyone understanding what the release schedule is because if we're saying, oh well we're releasing every two weeks and the client is like, well, no, I only want this thing released when it's this amount of features or vice versa, which tends to happen a lot where a client will say, oh, well we need to release right now. And you're like, well, these features are not actually completed and tested and ready to integrate.
Andrew:
Right.
Cris:
That's based off the fact that we still have one week left in the sprint because we planned it and we prioritized it and this is what we needed to do. Just making sure everyone's on a regular release schedule can obviously help with communication and ultimately help save on your investments overall. Anything else we didn't touch on, things that we do, things that people should be aware of when they're trying to go build a project that are those, I would say those pitfalls of where you're really going to lose your investment opportunities?
Andrew:
I mean just lack of planning. That's why we like to get people to do road mapping with us.
Cris:
Yep.
Andrew:
Lack of doing it, an MVP or minimum viable product.
Cris:
Okay.
Andrew:
So we want to identify what's the minimum value we can deliver early so you can get feedback. So those kind of things. Trying to go too long in between releases. So yeah, there's lots of pitfalls like that we can help people steer around.
Cris:
That's good. Well, I look forward to obviously working on some new projects in the coming months, year, and hopefully whether people work with us or not, these are going to be some good ideas for them to not waste their investments.
Alexandra:
Thank you for joining us for this episode of Bixly Tech Tuesday. I hope you enjoyed that conversation between Cris and Andrew, as they talked about all of the ways that we as a company, help your company maximize the ROI when building an app. If you have any questions at all, go ahead and leave them in the comment section and we will get right back to you. And don't forget to check out the description box down below. We have a bunch of really?helpful links?in there, including a link to our?free custom software guide, which walks you all the way through the process of developing your own app idea and getting it ready for development. You can also check us out at?bixly.com?and right at the top, there's a button that says start my roadmap. And that gets you a free 60-minute call with Cris to talk about your next app idea. Until next time, this has been an episode of Bixly Tech Tuesday.