Okay. Awesome. Alright. We're right about the mark. Hi, everybody.Thank you so much for joining my session today, and I hope you all are having a great time attending such amazing sessions through this conference. And I hope people are absolute having an absolute ball just learning new things as they grow in their careers. My name is Pourba. I'm an engineering manager with Bank of America. I've been with the bank for almost three and a half years at this point. I've been in fintech for ten plus years. So I started my journey. I pursued my masters here in The US, post which I was I joined in as a junior developer with Visa card, transitioned to a staff engineer, and then I switched jobs to Bank of America.

Here I am leading two teams as an engineering manager here. A lot of what I do has to do with how are really onboarding merchant platforms really created. So, essentially, when you walk into a store like Macy's, for example, what is it that goes behind the scene in order for your transactions to be successful when you walk into these stores? So that entire platform is what Bank of America set sells as a product today, And it's been on for the past four and a half years at this point. So I'm very proud of the products that we create. I'm very proud of the team that I'm part of. A big part of my role is to ensure that my team has complete clarity on what we are delivering, on what we are understanding while we are working with our product teams. So EMs at Bank of America are very hands on.

So they really know in in in-depth what is really happening in terms of not just from a high level design, but also system level design, which is why this topic is really, really dear to me because I go through this process almost every single day of my life. When a tech team works with a business team, there could be various versions of issues, various versions of problems, various versions of applications that you deal with on a day to day basis, which is why it's important to sort of organize your thoughts and really make sense of if a line of statement like design and x y z is given to you, how would you go about breaking that down?

And that is essentially what my session talks about. So before we even dive in to what what is it that and how metrics that you could derive from this process, Maybe let me explain you the challenge that we are facing on a day to day basis. I don't know if how many guys of you remember Google Wave. This was a product really, really long time ago, when this probably way way before Slack. So Google Wave was a product which was, a part email, part chat, part Wiki. It was a bit confusing to really understand as to what was the concept behind this product, really. Where was it going, and how do you really link all of it together?

The engineering aspects back in the time, this is probably very early February where you had so many things that a single chat box could offer. The idea, the concept, the engineering of it was pretty top notch for that time, but the product itself did not reach the right audience. It did not really understand the kind of processes and the kind of product that it's really offering and what's the benefit of a consumer like me who's sitting here and trying to understand this product. So it didn't really take off, and it was discontinued a few years after which it was launched because of the lack of lack of just the amount of volume that people were already using that product was very low, and they decided to shut this product down. So that's one example of what happens when engineering is really aligned with what is it that you want to offer, but the product is sort of not understanding what your audience is. The other example is of Samsung Galaxy Note seven. This was probably in 2016. This is probably when the iPhones had really taken up the market a lot.

So there were Android or Android software formwares, which were really competing heavily in the market to sort of capture the market. So Samsung Galaxy was one of the products which was launched in 2016, and it offered a very long battery life. It was probably the last one which had, like, the physical button with the that screens on it. What really happened is they wanted to get into market really fast, which essentially was probably not the most best engineering decisions at the time being because almost, like, two or three weeks into the market, the battery started to blow up. So the phone basically caught on fire. And that was an issue where too big of a battery size was was sort of packed into a very small framework of all that.

And this is probably one of those examples where the product overview or side of how to capture the market was there, but they didn't have enough time for engineering teams to actually sit down and test the products because we just had to meet very regressive market timelines, which is why it's important for both tech as well as business teams to sort of align with each other to really understand what is the vision what is the problem that we're trying to solve in the first place.

So I wanna walk us over with, like, some examples. Like, how how can we break stuff going further? Let's say you are in a call. You're sitting with product teams. You're sitting with business to sort of convert a very vague problem into something that would be eventually translating into a story tomorrow. So as an example, you walk in into one of these sessions and they say, we have to implement a smart card that offers your time upsell suggestions, dynamic pricing discounts, personal recommendations to increase average order value. That's such a overwhelming statement to begin with. This is essentially where your skills of truly mastering and understanding the product really comes into the picture here. So don't think of a problem given to you directly from an engineering lens. Let's break it down into metrics that sort of makes sense from a client perspective as well as from the perspective of the business.

So I've jotted down certain metrics that I look for whenever we are creating a brand new product or even a feature within that product. The number one thing that you need to focus on is what is it that you wanna solve, essentially the objective of the problem. In this particular problem, we want to ensure that, well, my business benefits in terms of revenue. And how are we gonna do that is by selling you personalized and discounted strategies while you're trying to shop on our platform. That's the objective. So let's simplify this problem from a business side. For somebody who's actually selling this product, this is what I wanna do. How would you really track that? I would track that by ensuring that the average order value of the consumer who's trying to buy on that platform increases.

How does it increase is through providing them really good customer experience, ensuring that they have very clear value propositions called out, and their entire personalized shopping experience is pretty much seamless. Through the launch of this product, is there absolutely anything that I need to ensure that needs to be delivered, which is what I call as constraints? So, essentially, while we are delivering these things to our to our customers, I need to ensure that the promotions are still attractive enough. If it's something like a 5% discount, is it good enough to begin with? So these are the constraints when I'm building my product. And there is compliance and feedback, which is essentially the aftermath of the product. Compliance is to ensure that we are suggesting and we are we're suggesting things which are really transparent and compliant so that the customers really trust us.

Given we are a new platform, we need to ensure that they know that we are offering them true products. Post the launch of these products, what is it that I need to do to understand my product is really working well? So it's not that we push things into production and there's a magical one and everything works fine. I would say 99% of the times, that doesn't work. So what can you do to ensure that your product is going through these iterations of building something that your customers really want? And you can ensure that you can get feedbacks by monitoring customer engagement, by your suggesting items that they truly really want and your interpretation of what they want. So you're trying to optimize all of these through the these different metrics.

Do you do you need to think of these from not so much from an engineering lens, but from a product lens. Once you sort of have come down to these basic metrics from a business perspective, that's when you start converting them into a tech perspective. So all of these metrics that I spoke about are in the aspect column that you see here. We want to convert them into tech perspectives. So one example I don't wanna go through all of them, but, like, one good example could be increasing the average order value. Right? What does that mean? From a tech perspective, that means that we wanna build a very scalable, almost near to real time recommendation with the pricing system. So all of these metrics have to make sense and have to fall down in the right bucket of what tech is supposed to solve.

The customer impact that we spoke about where we are offering them personalized deal, where we are offering them, like, an improved shopping experiences, what are the effective algorithms that I need to run on the back end? What kind of AI models do I need to run on my back end so that they're absorbing the right correct amount of data and providing them enough information to provide them that seamless experience? So all of these business perspectives are converted into some sort of, like, a tech metric. Of course, you can expand and subdivide them as per how your org decides to. Within that, obviously, you can have things like efficiency, your SLAs. Those two can be added as a part of this. But that comes a little later. The original ask of of the project is to ensure that you're breaking down very complex business problems into tech initiatives.

So the way I think of this is the tech perspectives are in initiatives to begin with. These are not stories. These are not Jira items. These are essentially big initiatives. These would further go down the lane where you're talking about really small features. Even building a scalable system is a is not really a feature. It's an initiative. So how do you really think about breaking it down further so that that eventually becomes features? But the idea here is that you break down a very complex problem into subsets of simpler solvable initiatives. Once you get there, right, once you have those initiatives something I always keep telling my team is Rome cannot be built in a day. It takes a while. Yes.

It would be amazing that by end of one week, I I give you the shopping cart that's available, and we'll get it to production in a week. It's hard. And even if we get it to production in a week, I'm I'm pretty sure there would be an ample of issues that we can possibly find. So we don't wanna get to production without really knowing the amount of impact, without actually testing the right amount of test performance, feature testing, whatever that your team really runs to get to a successful production level. So that's where a prioritization matrix comes into the picture. So if you see my screen, I sort of broke it down into, like, four bigger quadrants. So the red section, which is the first priority, that's essentially where the urgency of that initiative and the impact for your business is extremely high. So example, launching a new product itself where you're giving its base features. You're providing the most minimal capabilities. Is that the most critical part of this entire product?

If yes, that goes into your first priority. Followed by the yellow segment, followed by the blue, and then the gray. So once you have sort of broken down those tech perspectives, give them these numbers on a scale of one to five. There is an impact scale. There is an urgency scale, and you sum them up, and that's your total score. So, essentially, think of it as you're trying to build blocks as you move on. Don't try to think of building the whole thing in a goal because most of the times, you'll try to figure out as you as you go through the whole process. Launching a new product might itself have a bunch of things that you need to resolve before you move on to your second priority. So, essentially, we you need to get on the same page as businesses. Like, let's deliver this first. Let's get this out first.

Once we have gotten enough feedback about this, let's move on to the second. And this matrix would really help you help your product team really understand what is important at work. Once you've gone through that, and hopefully, you get things into production, I'm sure it's it's gonna be a difficult boat to sail to get to that point. In this whole process, in an engineering org, you not just deal with business who may or may not be technical. You also deal with other applications who have a very different lens of looking at things, which is why communication and and jotting down the things that you really agreed on becomes such an important part of the entire process. Number one thing that I I I tell myself as well as my other peers who are in these sessions with me is to set very, very strong communication channels.

If we have agreed to something, even if it means one plus one equals to six, It I I need to document it, and it needs to be on this common communication channel that we agreed on. So it could be your Jira. It could be your conference pages. It could be your Slack, whatever it is that your team really supports. It needs to basically have that stamp of approval of the documented decision that we've agreed on. Keep it concise. Don't get too verbose. Don't put, like, paragraph of, like, 50 sentences to essentially say one plus one is equal to six. It just should say something really short, but ensure that you're defining that in a common common communication channel that you have. Even through all of this process, there will be times when there are a lot of disagreements, especially when working on a product.

You're working with maybe 15 applications at a time. Everybody has their own opinions to give. Ensure that you're working with the TPO or the the product owner to ensure that there are decision makers through this process. It needs to be a technical decision maker. It could be somebody like an architect of your own. It could be a nontechnical decision maker, someone who actually performs things like, oh, these are the business requirements from a client's perspective. This is what they're actually expecting to run these things into. Ensure these are preset before even your sessions really begin. Documenting those sessions which we which I call it ADRs, which is architectural decision records. Once you actually have those decisions, document them in a common channels that you have.

Even through that process, there will be times that, well, you still didn't agree with the final solution that was made, which is okay. But as long as this final decision maker has the ability and has decided this is gonna be the path forward, you must publicly commit to executing it even if you are privately. If you have set up these decision makers in your entire ecosystem, they're there for a reason. So if you are the only disagreeing party in a in a party of 50, it's the final decision maker's call, and you have to respect that and move along with it. So, yeah, these are the few key takeaways that I would recommend while communicating in a while while working on a very, very big product, while you're working with almost 50 to 60 people to come up with a brand new product or a new feature. I think I do have the last three minutes, but if you wanna connect with me, here's my LinkedIn.

I'm gonna open the stage for any q and a's, any questions that you have. If anybody has questions, you can put them in the chat. I don't know if you guys can unmute yourselves and ask me those questions, but feel free to put them in the chat and I can answer them for you. Not seeing any come through. Alright. If there are no more questions, thank you everybody for spending your twenty minutes with me. Hope you have a good rest of your day, you enjoy the rest of the sessions in the conference. Thank you so much. Bye bye.