Technology Roundtable – High Performing Tech Teams and Top Product Managers – Building A Bridge to Success
Wonderment Apps is proud to present the Technology Roundtable, our insight series that shares insights into the technical management and product handoff process. As a group of experienced technical managers and product developers, we would like to provide insight into the technical processes and best practices in the lifetime of a product buildout. In this episode of the Technology Roundtable series, we will explore the product handoff process between product management and the tech teams. We will discuss how we work with the product management team to create the best possible handoff for the tech teams to receive the best insight into the product and engineer the right solution.
We will be focusing on optimizing the product handoff process for the product team to translate the tech team’s product requirements. At Wonderment, our team has established the tech team’s required procedures to partner up with the product team throughout the lifecycle of technology buildout.
—————-
Technology Roundtable Transcript
High Performing Tech Teams and Top Product Managers – Building A Bridge to Success
[00:00:09.490] – Ryan Williams
All right, welcome, everybody. We’re excited to be here this morning. We’re going to be doing our Wonderment Apps Tech Roundtable for this week. We have some exciting things to share about the technical processes that we face here at Wonderment Apps and we know exists for everybody working in tech teams management. Across all tech teams companies in today’s topic, we’re going to explore a little bit about the handoff process between product management and product development into the tech teams. What are some ways that we can optimize this process? What are some of the challenges we face and how exactly do we approach this particular issue to create the best possible technology we can today on our tech roundtable? We’ve got a great group of engineers here from Wonderment Apps. We’re excited to share their thoughts and how they approach these things.
[00:01:08.410] – Ryan Williams
So we’ll go ahead and introduce each one of them to you. The first step is my partner here at Wonderment Apps, Faraz Tabibian. Can you tell us a little bit about yourself, what you’ve done in the past and kind of what engineering is to you and some of your experiences?
[00:01:25.070] – Faraz Tabibian
Thank you, Ryan. Hi guys! My name is Faraz Tabibian, I’m one of the co-founders and partners at Wonderment Apps, I have years of experience building and architecting technology solutions in many different verticals such as e-commerce, media and entertainment, SAAS businesses and finance. After being the clients of a number of different product and technology agencies about six years ago, Ryan and I decided to just start an agency, a product and tech teams agency to really connect with client needs and provide the best level of product and technology solutions.
[00:02:13.850] – Faraz Tabibian
It’s been a very interesting journey and we had the experience of working with a number of big sites, clients such as NASA and Stamps.com. And I think the journey continues on and we are definitely super excited about that.
[00:02:32.190] – Ryan Williams
Awesome, thanks Faraz. Next up, Meenakshi Rawat, can you tell us a little bit about yourself and your engineering history?
[00:02:43.310] – Meenakshi Rawat
Hi Ryan, thank you so much. Hi, everyone, my name is Meenakshi Rawat. I have been working with the Wonderment team for almost five years and during these five years, I have been working along with developing and managing technically oriented solutions for different lines from startup to enterprise clients. We have been involved in managing and building a number of legacies, as well as from a lot of new applications that we have built from scratch. We bring a lot of diversified experience for our clients. So whatever the platform required for the front end or back end or the infrastructure device, we always put together all the requirements and build a custom solution. We also make sure that we follow the standard of process across our development and project management journey so that we bring the same quality for every client. Thank you.
[00:03:36.440] – Ryan Williams
Great, thank you. All right, and next up, we have Tymofii Nazar. Tymofii is out of our Ukrainian office. Can you tell us a little bit about yourself?
[00:03:48.880] – Tymofii Nazar
Hi, Ryan and everybody else. I’m right now a technical project manager at the Wonderment Apps, and I’m really excited to work towards making a collaboration between the public visionaries and tech teams, bringing that to the next level to make it the more pleasant and enjoyable experience while doing a different type of technology like building the websites or mobile solutions.
[00:04:15.950] – Ryan Williams
Awesome. Great, thank you so much. This is a great team that we have here. We’ve been building products, as Faraz said, for quite a number of years. And we have worked on everything from kind of small startups that are trying to explore ways to create new innovative technology. All the way to enterprise has kind of more set foundations in the technology that they’re building, but they do it at large scale. So one of the great parts is this team is run across a lot, a lot of challenges over the course of time. And they have some great thoughts on how to handle some of those. So today’s topic of discussion is how do we work with the product management team to create the best possible product handoff process that’s going to give the tech teams the right kind of information and insight to engineer the solution right out of the gate.
[00:05:09.880] – Ryan Williams
One of the big challenges that happen in this industry is that that communication breaks down. So the vision of what’s happening on the product breaks down when it gets to the engineering team and things actually get constructed incorrectly. So there’s a real need for a very good communication in the product handoff process right at that point so that we can create the best possible technical products that we can. So Faraz, I know you think about this a lot, and I know this is like one of the big spots that you’ve worked on in your career, certainly in the last couple of years. Can you tell me, like at a high level, what are some of the important spots that you think about as you receive something from the product? What are some of the big things that have to happen in that? And how do you prepare?
[00:05:59.890] – Faraz Tabibian
Sure. So I think the tech handoff is the most critical step in any technology buildout because there is a translation that needs to happen from the production departments on the vision of the product to actually the actual execution. And oftentimes there are things that get lost in translation as part of this process. So I’m Wonderment Apps we have very clear processes and guidelines and checklists in order to ensure that this translation happens at the highest level of quality. Some of the things that I would mention that some of the most important things as part of this process could be stuff like assessing the feature sets, the annotated wireframes, the sitemap, the user flows and the requirements and making sure that there is early feedback that’s going from technology to the product team. And obviously things like project planning, timeline estimations, the initial build-out cost. So there is a variety of different things that we look at as part of this translation that I’m happy to actually go into the depth.
[00:07:24.040] – Ryan Williams
Great, thanks so much, Meenakshi, when you receive that handoff from product management. What are some of the kinds of initial high-level things that you have to keep in mind? And what are some of the challenges that you faced around that?
[00:07:38.990] – Meenakshi Rawat
So then we have to see what initial hand out so we look for as a technology, we look for many things when it comes, it should be very big, right. So when someone is giving me a feature, so might be a feature for the client, but for us, it might be a whole flow. It may not have been defined in a way that it could have been. So we fill those missing pieces. So when we get the look at the flows, we ask the right questions now and then? Not only use the flows, but we also look at the other aspects of that for what kind of scale it needs? what kind of metrics? A lot of other features that might not be related so we ask the right questions at the right time so that we know what we are going to build exactly. But then depending on the later stages, oh, this is also something that should be better be followed. So that’s the way we plug in those gaps at the right time. And I think that’s what keeps on going on. That’s what gives us the right success path when we are involved in the first flow.
[00:08:36.110] – Ryan Williams
Thank you. I know one of the things that you mentioned in an earlier conversation that we had as well as that it was important for the engineering to lead to be in the conversation early with the product as well. To you felt like that was an important part of the product handoff process, correct?
[00:08:54.080] – Meenakshi Rawat
Yes, yes. Yes. So as I said, like, you know, there’s a feature, but a lot of technical aspects of this. So how we are going to build it with what platform, what kind of infrastructure we are going to use, so to come to that decision. A lot of questions. You have finally to be answered by the product team that not something tech teams can get on its own. It’s very important that we are involved in the day. We can go back to one of those questions and give them a lot of options other than looking at one thing and then they’re on very initial phase or something they’re asking or these are the options which we can build. This will be the cost for this, those kinds of analysis which can be done timely. And we can say, well, maybe we can understand more exactly what the client is looking for.
[00:09:39.680] – Ryan Williams
Yeah. It’s great. One of the things I know in our process at Wonderment that we really focus on is including the engineering leads in early product sprint processes. So we actually like to have an engineering voice even as we’re doing the designs of the product so that we can actually work on the prototyping with them and have them think about this. As Meenakshi said, things like cost and timeline can be greatly affected by a small decision that happens within that environment. Thank you. Tymofii, how about you? Like, how do those things impact you as well? Like, what have you come across?
[00:10:23.240] – Tymofii Nazar
So one of the challenges and goals to me when I receive our products back or, you know, the description of what features we want or what type of product we want to build is to find out what are the most important key features that can be built in the first place, like a phase one, and then the rest of the features that we can sacrifice or postpone to the later stages of the development because we are living in a world of constraints and we want to find the shortest path to the possible. We know when we built into that solution.
[00:11:02.570] – Ryan Williams
Yeah, that’s a really good point. I know in the product handoff process, one of the amazing parts about product managers of which that’s my background so I know is that we get to dream a lot, so we get to come up with a lot of great ideas. And sometimes we deliver those dreams to engineers and they’re like, that is a lot. That’s huge. So like you said, how can we carve that down to where we get to maybe like an alpha perspective of how you would deliver something in a timely fashion that has kind of the core foundations of it? Right. It has the elements necessary and then and then build. Right? and then we start iterating and sprinting on top of that. Correct. Yeah, that’s really important, so Faraz. Can you tell me one of the interesting points that were brought up in here a minute ago was around tech stack? How early in the product handoff process do you think about what tech stack should be used and when do you know that it’s the right thing?
[00:12:05.230] – Faraz Tabibian
Very early on, so almost from the first annotated wireframe, so you start thinking about tech stacks because it’s a balance of performance versus costs. There are some amazing tech stacks available out there, but they’re expensive and the costs of using those tech stacks can be significantly higher than other ones at the same time. Maybe using some of the tech stacks could be a lot faster than some other ones, so you just have to find the right balance for what we are building. A great example of that is let’s say you’re building a video pipeline, a video gets uploaded, and then it has to get transformed and to many different formats. And that, you know, that can be a complex task, you know, if it’s a large-scale website. So really like going and doing the investigation and making sure that you’re looking at every available technology stack and you’re choosing the one that does the right fit. And it basically matches the budget and it also matches the speed of development.
[00:13:18.010] – Ryan Williams
And the right fit that you’re talking about it might be directly related to what the product is doing. So you brought up a video pipeline, right? There’re better tech stacks for certain video pipelines than others or there could be like if you’re doing large scale data ETL transformation project, things like that, you’re going to be influenced by those stacks as well if the company is maybe a startup that’s got a limited budget that can work with it versus enterprise, which is looking more for security and safety. Right?
[00:13:51.880] – Faraz Tabibian
Exactly so like really looking at what you’re delivering to the end-user and making sure that you’re not over-engineering that piece and just keep evolving, you know, maybe something really simple works for day one to just get a POC, a proof of concept out there. And maybe you could just do something really small and maybe later on you can revisit that and do it better and continue thinking about technology scaling along the way. But I would really, really pay attention to not overengineering day one.
[00:14:33.880] – Ryan Williams
Great, thank you. Meenakshi, what do you think about making the tech stack decisions? What are some of the qualities that you’re considering?
[00:14:51.160] – Meenakshi Rawat
As Faraz mentioned there are already a lot of signs, but the few other very important criteria are when we decide on that. So, first of all, we look at the requirements of what that project is? Depends a lot on if it is a project for something which is very highly business computation is going on or is just a delivery system that something is stored and we are delivering to the user. There’s not much business computation going on. So based on these criteria and also how we want to build and how what kind of scalability is going to be. There is a lot of the kinds of devices are we going to be? going to support a lot of standardized devices in the market. Also then we need a standard React JS, but it’s different to a simpler desktop so we can just build something and something small which is on the HTML application. It is a lot of it that depends on the project requirements, then we decide these are the requirements. What’s going to be computation heavy then? I should have like something very strong Java. If it is an enterprise application, then otherwise, since a simple delivery from content, from the database to end-user, it can be a simple Node JS application. So depending on those, also we come up with the right platform for the project.
[00:16:11.040] – Ryan Williams
Yeah, one other thing, maybe you or Tymofii can talk about this, but one other element is the sustainability of the tech stack you choose. Tymofii, maybe you can talk a little bit about this, that sometimes there are really attractive technical solutions that may have a limited number of developers that can code in it. And you may want to try those. But it also may put the product in a position sustainably over the course of time that is hard to find developers to work on it or find. Can you speak a little bit about that?
[00:16:49.330] – Tymofii Nazar
Yeah, exactly as you mentioned, there are all of you facing the problem that some part, some specific developers, maybe there are maybe more of them available in the market and there is another developer that is less available. So when you’re choosing the right stack, you have to take into consideration what teams do you already have? Whether you want to work or don’t work with tech stack. Do they have the right experience in that? Can they start performing from day one or whether they will need a lot of time to be on board with that? So that’s one of the things.
[00:17:33.330] – Ryan Williams
Great, thank you. Yeah, I think when I’m comprehending the impact of what a tech stack is going to have on the life of a project, it’s pretty sizable. So it’s a really important decision upfront, some other really important decisions that come into place, as well as like how we’re working with the foundational architecture of a project. And I know one of the early ways that the tech teams assesses what that architecture has to be is they actually have to dig in and see the way that the flows and the wireframes and all the kind of concepts that are happening in the product stage are going to actually translate into a technical foundation environment. Faraz, how do you assess user flows and wireframes and think about that process to create the kind of the most efficient backend or structure that you’re going to have to build on?
[00:18:31.770] – Faraz Tabibian
Sure, so having done this for a number of years, we have put together some really good guidelines and checklists for the most common feature sets that we build. As some examples of that could be, let’s say, your building authentication and authorization. And so there are some like top 20, top 40 common things that we always look at. And we make sure that we see them in the annotated wireframes and having those checklists in place, we make sure that we communicate very early on.
[00:19:16.960] – Ryan Williams
What are a few of those top ideas that you can think of?
[00:19:22.770] – Faraz Tabibian
Yeah, sure. So we make sure that number one we are connected to the requirements when it comes to performance, something that can be done in five hundred milliseconds can also be done in 50 milliseconds. Right. But is it worth spending the time? Right? so those partnerships, let’s say, like, OK, so like what are the performance requirements like? Do we really need to focus on that and also make security best practices? Like is it a banking standard security or is it something less than that. Right? To make sure that we are always connected to the requirements and take a look at our checklists and making sure that we are actually connecting with the product needs and building something that’s connected to what the product team is asking for and not something more than that.
[00:20:22.660] – Ryan Williams
OK, great. And it’s great to present ideas during that initial product engineering period as well, so they can kind of expand their horizons and what’s possible. So Meenakshi so actually maybe you can talk a little bit more about this, too, when you receive user flows and wireframes. What are some of the spots that you actually go in? Some of the most important spots that you go in and you assess in the early stage that will impact technical development?
[00:21:07.620] – Meenakshi Rawat
Yeah, so you know initially receive wireframes and user flows. We need to review them in-depth. And we generally look for an end to end flows from where they’re starting and where they’re ending on making any sense. Is there any kind of especially when it says to upload a video, who is uploading the video, where this video will go? What has to happen with that video? Right? so all those small things and the things we try to if it is not in wireframe we would look for questions or video of someone saying, so what other types of videos they use, again, what is the size, what are the validation issues and what kind of process they want to show on the wireframe. So these are the specific details which are we looking for apart from there what are the user types? And you say user flows and what are the user types of what is the audience? How they are related to each other. So that’s what we are looking to.
[00:22:08.350] – Ryan Williams
And like you are saying the user types specifically, that’s a good example that actually can affect what permissions have to be set throughout this right? so different users might have very different experiences.
[00:22:23.450] – Meenakshi Rawat
Yeah. Exactly! it is good for admin. Maybe it might be related to when it comes to user types. It has to be content-related. What content is accessible to which user, what functionality that is accessible to that particular user. We are monitoring what metrics are for those users, how they’re connected. So these kinds of things which we look for in user flows.
[00:22:46.680] – Ryan Williams
Yeah and I know on the product side, we’re thinking about that from an audience perspective as well. Right? So what can impact the actual usage and adoption and obviously the retention of the product over the course of time? So can we create the right kind of technical tools for that? That’s really good. Thank you, Tymofii. When you receive some wireframes and user flows and some of the other assets from the product, what are some of the initial things that you find really important that you look at?
[00:23:15.070] – Tymofii Nazar
Well, first of all, I’m trying to assess and understand whether there is a shorter path to success for some features.
[00:23:24.750] – Ryan Williams
Yeah, that’s a good one. It’s a good one.
[00:23:27.120] – Tymofii Nazar
And the second part is about the corner cases usually they are not well thought out because of our nature. We’re trying to think about the positive cases. Right. But when you’re drawing a UML diagram with engineers and trying to actually put the names of parameters that are feeding into the system, which we are discovering a lot of the points of black spots where we can discuss and improve the specification. So that’s it.
[00:23:56.560] – Ryan Williams
Yeah, that’s a great, great example. I know we do think a lot in terms of a happy path, right? so that we can kind of take users down to one that’s really successful. But the truth is, there’s actually just and oftentimes just an extensive number of potential options or variations of end result that can happen. And that is like one of the engineering challenges is like, can you envision all of those scenarios before they happen to the user first? That’s a big challenge.
[00:24:28.240] – Faraz Tabibian
Yeah. And also just to add to that Ryan. I think oftentimes a lot of these things get caught after we translate the product user flows to technical user flows. And during that translation, we catch a lot of like early, early misses. It’s a great time to catch them because it could get a lot more expensive a month down the line. So thinking about those like technical user flows, day one and making sure that the technical user flows are on the same page as the product user flows, I think that can add huge, huge value to the final buildout.
[00:25:09.640] – Ryan Williams
Can you describe really quickly what’s important to document in your technical user flows? Like what are some of the key things that you have to make sure in there that maybe aren’t coming from the wireframes?
[00:25:21.280] – Faraz Tabibian
Sure, so often times there is an algorithm that needs to be basically thought of as part of the product requirements and the product requirement does have all the use cases, it has the business scenario and all of that. But once we actually put this algorithm on a piece of paper, as Tymofii said, how about this piece. Like what if this happens? What if there is a 404 at this step of the process. What if this service is not responding as part of this bigger pipeline? Right? there are a lot of what-ifs that we catch during the technology user flow. And we can immediately go back to the product team, and be like look this needs some more information. So I think capturing those very early on can actually introduce a lot of cost savings to the final build-out of the project
[00:26:27.560] – Ryan Williams
That it’s huge. I agree. And I think it also presents just a number of another kind of openings in engineering that has to be developed that a product person can’t see on the page and has no idea. And I know that’s a common scenario. Meenakshi, what are some spots that may be the product people often don’t think about when they’re creating the wireframes? Are there some common areas that you technically end up having to bring into the picture?
[00:27:01.750] – Meenakshi Rawat
Yeah, very often we generally see missing and what are the kind of validations are there? And let’s say there is a form. Then fees on it. So generally most of the time, what kind of validations have to be applied to their site and what kind of messages has to be there? Sometimes they submit a form and there’s no message. What is the success message we have to give? Then when we get these things, then we are actually implementing and then we find it missing. Oh, this is missing. But these are the things which are defensive already in the wireframes. So this makes the overlay process smoother.
[00:27:41.130] – Ryan Williams
Thanks, Tymofii. How about you? Is there anything on this front that you find that the product teams regularly, they may not know, but something they do can impact the technical development side?
[00:27:53.710] – Tymofii Nazar
Yeah, sometimes we will miss them the moment that not every area in the world has the same good quality Internet connection, and when we build in their software, we have to take especially the one that relies on the good connection. We have to keep in mind that there will be a lot of places when we’re trying to grab some data from the remote center or push that to that place. And in case if there is a really laggy connection, the user might see that some strange views. If we don’t put the right law there or you can click book taxis twice if we don’t block the UI layer and what will happen next to taxi drivers. So those like things, we have to envision them and prevent those from happening.
[00:28:40.760] – Faraz Tabibian
Yeah, that was really a good thing. Thank you. And one thing that I want to add my number one favorite item is business logic translation. And as I said, product managers are storytellers. They want to tell a story and engineers are a little more 0 and 1 and they are after exactness and accuracy. So I think like that’s when the technical project management can play a very important role that OK, how do we translate this story into something that’s a little more like 0 and 1 with like if statements. So oftentimes what happens is that we receive the requirements and then at the very early stage of the process, we look at these feature sets and these requirements and you’re like, oh, OK, this is good. This is great. But we need to add some translation on top of that. So that’s when the technical project manager gets together with the product manager and they partner up and they work on these translations together.
[00:29:51.210] – Ryan Williams
Yeah, I have a good one for you actually on this that I think you’ll enjoy this question, one of the things that often is not translated very well for the product manager because they don’t necessarily think about these things is the impact of infrastructure on some product decisions that are made. I mean, you brought up the video pipeline earlier, right? One of the big things is like the infrastructure elements tied to that, depending on the scale of the project, could be so significant they never thought about it. So that translation gets missed. Can you talk about how infrastructure is like a spot in here that’s like one that we sometimes hit and sometimes miss?
[00:30:32.970] – Faraz Tabibian
Yeah, definitely. So infrastructure is mostly on the technology side of things, but in my opinion, it’s a partnership with the product team. And the reason for that is you really need to define the application scalability and traffic requirements. Day one, so building a video pipeline for a one hundred user base website is pretty easy and anyone can do that. But what if you’re receiving one hundred requests per second and all of a sudden that becomes a very complex technology challenge? So we have a very detailed questionnaire that we actually presented a product team and the client and as part of like we have about forty-five questions that you really like, try to define the scalability and the traffic and the traffic growth in the next three months, six months and one year. So to make sure that are predicting and thinking about these traffic growths in the short run and also in the long run. So that’s one of the biggest ones. And then there are also things like choosing the right cloud infrastructure. You know, there are so many cloud infrastructures available today.
[00:31:49.740] – Ryan Williams
Yeah, It’s a lot.
[00:31:50.990] – Faraz Tabibian
Yeah, there is. And then every cloud infrastructure can have advantages and disadvantages. But again, working with the product team, you can really define the right cloud infrastructure for the right client. And there are things like you use a region where the user is distributed in the globe. Are most of your users in the West Coast? Are they in the East Coast or they are in Europe? And knowing this information, you know, it’s going to help you like to distribute the right servers and the right instances in the right part of the globe. And obviously, there is the architecture of the infrastructure that can be extremely important, just making sure that you’re architecting your cloud correctly and obviously the hosting cost, like making sure that you choose the right technology in your cloud. And finally, the security requirements and assessing what security requirements you need to be implementing for your application, asking the right questions and implementing the right solutions.
[00:33:06.870] – Ryan Williams
Awesome. Yeah, it’s huge, I think you brought up something really interesting, too, which is really around making the right or wrong decisions around the cost aspect of things. And I think that also one of the other aspects that we think about, as well as how the timeline can be impacted unexpectedly like this, so Meenakshi maybe you can talk a little bit about like what are some things you think about when you look? And infrastructure is a good starting point. When you look at the cost and the timeline, how do you evaluate that based on the assets that you’re receiving from the product? What are some things that you do?
[00:33:46.750] – Meenakshi Rawat
So as Faraz mentioned, scalability is one major reason which plays a major role in the cost of the infrastructure. But apart from that, we also look into what kind of availability and is looking at the client looking for. Right? so let’s say I have set up a cloud and it’s not in my infrastructure. It’s cloud infrastructure. So they sell it to it. It may go down. So is how much the client wants. It’s okay to go to the client side to go for five minutes. It’s okay to go down for one hour if they’re not okay with it. Let’s say it’s an enterprise application. Right? so there would be a lot of extra infrastructures. We will be preparing so that if something goes wrong, we can quickly put up another region. Next to that is very, very high. It is very good, but it comes with a very high cost, all the availability and eligibility options. I think that’s one which plays a major, major role. Let’s say one might be because don’t we have another database available so that I can switch over, but it costs you double right? The client is going to pay for this at the ready. Meanwhile, I should be able to get from the backup and it’s taken us if the client is ready to take the side down for one hour. So that kind of question also comes when we design the infrastructure.
[00:35:10.490] – Ryan Williams
Great, thank you.
[00:35:11.360] – Faraz Tabibian
And I’m so sorry, just to add to that, Ryan, like often times it comes down to redundancy requirements that the client is like, I want to have ninety-nine-point nine percent uptime. And then you’re like, OK, like in order to guarantee that, you need to make sure that you have redundant servers in different regions of AWS services. You know, you’re in West, you’re in east and even within West, your different availability zones. So oftentimes it’s just looking at the requirements and making sure that, OK, if you’re looking for ninety nine point nine percent uptime, these are the cost implications. And then making sure that you choose the right redundancy for the clients depending on the needs.
[00:36:00.060] – Ryan Williams
Yeah, that’s huge, and that has very real costs associated as well to it to be able to have that kind of security of the uptime and security and consistency. Those are all elements that have to be communicated back depending on the feature sets that are chosen by the product. There’s some other big cost that takes place as well that we have to think about, which is just the actual development or construction costs that go into the process. Tymofii, maybe you could talk to us a little bit about how you look at some of these assets and think about resource allocation based on cost or based on skill sets and what you need to analyze and related to that.
[00:36:41.880] – Tymofii Nazar
Yes, of course, but basically, we were if we are dealing with existing tech teams, we would want to know what is their past experience? With which a cloud solution they have worked in the past because right now almost every cloud solution has a comparative service on their list of available features. But you can use almost every cloud environment in the wrong or in the right way so that you can load, for instance, you can have a fast database and you can put a heavy file into that. And instead of putting it in the cold storage for persistence. Right? so assessing the best experience of engineers, who were on the board and deciding what they have experience in will be a major driver in this decision.
[00:37:47.160] – Ryan Williams
And what other decisions? So let’s say you receive a set of wireframes and business requirements. What do you look for quickly to decide what development resources to put on it?
[00:38:03.170] – Tymofii Nazar
So you’re not talking about the cloud?
[00:38:07.530] – Ryan Williams
So I mean it’s all of it. you have the infrastructure, you have development, and then maybe even QA. I mean all these pieces come into play. But that specifically for development like when you look at them. Like how do you say, I think I’m going to need a senior developer for this or I’m going to need a junior developer here. What are some of the things that you contemplate?
[00:38:25.410] – Tymofii Nazar
So there are some basic best practices over coming up with tech teams so that everybody on the tech teams has a space to grow, to lead others, to grow in different directions. So, of course, there are like trends of having one lead and then one to seniors and then several mid-level engineers. But to be more specific. When you’re receiving the requirements.
[00:39:02.270] – Faraz Tabibian
Just to add to what Tymofii is saying here, Ryan, I think a lot of times, you know, like you look at the complexity of the feature and also how much experience our developers have had in the past, like, for example, if you’re building a very complex search algorithm and they can get really complex sometimes. So you want to probably go and assign one of your senior developers who have, like, search experience in the past. If you are building a form that takes some inputs from like from the user and you’re just saving some parameters in the database. You could go with a mid-level developer to save some costs. So just really assessing the complexity of the feature and also looking at, OK, this person has done authentication in the past. This person has done a video pipeline in the past and has done search algorithms in the past or like all the other technology features. And I think that could actually introduce a lot of cost savings.
[00:40:08.670] – Ryan Williams
Yeah, that’s great. Meenakshi I’m interested in hearing about this from you as well. I know you place a lot of tech teams members on the projects and have to think about those skill sets. What are some things that you think about as well as you’re going through this?
[00:40:22.280] – Meenakshi Rawat
Yeah, so as Faraz said the first thing which we always look at the requirements wireframes, but then we analyze what kind of requirement is it as more of a front and heavy side, which we are building back and heavy depending on the design and the complexity of each component. It has to be better than what it is. There is a lot of CSS and It is more responsive. Then we need UI developer and similarly for the backend engineer something which is what kind of skills are required for that backend the cloud also. And they should not also be some language specific, dot net or Java, whichever platform is required. So depending on this, what all has to be billed so we just come up with the right requirements for the source and then we see this is the right resource for this and also depends on the cost. It’s a very small project and even if they set something critical has to be done. But there’s not every then we decide the number of resources is required for it comes with a cost, but maybe that cost doesn’t fit, but maybe we can go with the lower end and put some extra the particular resource to build some extra skills over there. So that’s all it goes on.
[00:41:44.410] – Ryan Williams
So what I hear from you is there’s a lot of considerations when you’re taken into account. But the first thing you look at is do we have the skill sets immediately available to execute on it? And then how much of those are going to cost, depending on what they are and Faraz’ this point earlier, how complex is that feature to actually build? And if we stuck a lower cost, like a lower cost, but if we stuck a lower-skilled developer on it, would they be able to even complete it or would they do it in a way that was performing? So those are all big issues. Great. I think this is an excellent rundown of how we look at and assess the product handoff process between product management and tech teams.
[00:42:30.840] – Ryan Williams
There’s a lot more to cover here. We just kind of open the can of worms. But I think these are some big topics that we talked about today which really range from how we look at how resource selection infrastructure to thinking about how we handle all of the assessments of the wireframe and user flows and just look at the whole thing as one kind of big organic process where we have to communicate a vision that’s happening from the product team to something that’s actually executable by the tech teams and can be done within the time and the budget allocation that is possible.
[00:43:13.450] – Ryan Williams
I appreciate I appreciate all of you sharing today was great, great insight. And I’m sure anyone has taken the few minutes to sit and watch this will have learned a lot. Is there anything you’d like to say is we’re heading out? Faraz, would you like to say anything?
[00:43:29.280] – Faraz Tabibian
No, thank you so much, Ryan. As you said, there is a lot more to be covered and we probably need hours more to actually dig in and talk about this product handoff process. But I think this was a great start, and I’m looking forward to having more roundups and talking about this topic. Thank you.
[00:43:48.720] – Ryan Williams
Awesome. Thanks so much. Meenakshi would like to say anything?
[00:43:52.400] – Meenakshi Rawat
Thank you. It was a great session but all thoughts together when we thought we may not be even thinking that much but when we are specifically asking each and every question, it brings a lot of value to what we are thinking and how we are doing things. So it’s great putting them together here.
[00:44:09.680] – Ryan Williams
Thank you for sharing. And Tymofii, how about you?
[00:44:14.000] – Tymofii Nazar
Oh, yeah, I enjoyed this time and I’d like to ask the listeners to come up with their thoughts on this topic and write in the comments so we can all relate to them and maybe improve the way how we perform the handles.
[00:44:29.540] – Ryan Williams
Yeah. Now there are lots of developers and engineering leads that face us every day. So, yeah, it’d be great to hear some of the thoughts as well. So thank you all. We’re Wonderment Apps where we’re located, www.wondermentapps.com. We service to core lines of business. One is we do managed projects so we can take a project from start to finish from product all the way through tech teams into QA. So that’s number one. And number two, we have a great staff augmentation service line where we have very talented, well-curated developers that can execute on your tech teams quickly. So if you ever need any help, please don’t hesitate to reach out. Otherwise, we look forward to sharing with you more thoughts and just contributing to making technology development better all the way around. So thank you for having us and listening today. And that’s it. Thank you!