5/9 Critical Conversations You Forget To Have With Your Product Team: What's the technology landscape?

[00:00:00] Welcome to the Convergence podcast. I'm your host, Ashok Shivanand. It is for whatever reason very natural for folks to assume that you have software engineer, A wrote it in a certain language and you have software engineer B knows the same language that they should be able to pick it up and run with it. If only that were the case.

[00:00:19] On this show we'll deconstruct the best practices, principles and the underlying philosophies behind the most engaged product teams who ship the most successful products.

[00:00:36] This is what teams are made of.

[00:00:39] Welcome back folks! On this episode we're going to continue our series of nine crucial conversations that you might have forgotten to have with your team.

[00:00:47] Today we're going to talk about conversation number five which is the technology landscape. Before we talk about that though, I didn't want to play this question that came from one of our listeners Evan.

[00:01:17] Just a few years ago when the competition started to finally erode that. I've been wanting to use the nine conversations to re-align my teams and possibly even generate some new ways of approaching our customers.

[00:01:33] So my question is whether the nine conversations can be applied to an established product, particularly in an organization like mine that has been historically siloed or if it's only relevant to new product development.

[00:01:48] First of all Evan, thank you so much for sending your question in and also for clarifying something that we have likely forgotten to explicitly state.

[00:02:01] So with respect to your team and competition catching up, I think that's an amazing sign that y'all were early to market and were able to bring something a value to your customers.

[00:02:11] And of course, congratulations to that. That also as you're noticing carries a risk of having something to lose as well as in my opinion the debt or the burden of the reasons for your success to date because they're not necessarily the reasons for why you're going to be successful in the future.

[00:02:28] With respect to these conversations, they can be had at any time. In an ideal world you're having this conversation when you're forming your team.

[00:02:35] Everything's new, the team members are new, the initiatives new and having this clarity and context with respect to the priority of the organization.

[00:02:46] With respect to the problems you're solving, the target audience and everything else we're talking about here is really important. That all being said, we do tend to do what we used to call a re-inception at in a rural where we will go back and remind the team of what some of these crucial conversations.

[00:03:06] The reason for going back and having these can be varied. Sometimes there's a drastic shift in strategy, and we want to make sure that the team is growing in the new direction than where we were growing before.

[00:03:18] Sometimes there are some key personnel that get added or removed from the team and a lot of context or cultural momentum ends up having a risk associated.

[00:03:27] We want to apply some level of intention so that we can do risk and inertia that's not in the direction that we want.

[00:03:36] Our teams are, of course, generally going to use their best moralities and do the best they want.

[00:03:41] But having conversations like this can help them know how to be valuable to the team.

[00:03:46] And also I think raised questions, concerns and clarifications that similar to ever-nasking this question, I know that there are probably a few other folks that have wondered this.

[00:03:57] And it's probably the same when you're a product team where when you have one squeaky wheel or one person raising their hand, you can assume that there's a couple other folks that have maybe wonder something along with the same lines.

[00:04:07] I will say some guidelines though that you can also slice and dice these conversations. You mentioned silos and a larger organization, your part of that has already been successful.

[00:04:18] In those cases, you may have iterated your organizational structure towards optimization and scaling, which has a lot of benefits, of course, but also carries risk like the silos that you mentioned.

[00:04:30] And when you're going up against a competitive threat and you need to shake things up, it's important that you number one, in our opinion, have these nine conversations.

[00:04:40] I'm not saying they're exclusively all the conversations, but time and time again, when we've got into help get a team re-energized or help get a team back on track.

[00:04:50] These nine conversations seem to be the things that someone forgot to have with the team and clarifying and opening the doors for conversation tends to be an amazing way to save a ton of time and pain by being intentional and having it early.

[00:05:09] That being said, I do think especially in a siloed organization, what I would worry about more than having them all at once is making sure that over the course of however long you're going to take to have these conversations.

[00:05:23] Maybe it's a weekly Friday morning meeting. If you can't walk off two days for the entire team to get together, what's really important is that you have critical representation from those silos present and this is everyone from the product team which is a no-brainer.

[00:05:39] I would say in order to identify the stakeholders as a few questions I ask, one is who has approved the budget, who is accountable for a return on investment for this budget, who are the gatekeepers that can block something from being pushed to market or going to production.

[00:05:58] That could be legal or compliance, sometimes branding and other folks. Those are some of the other stakeholders that you want to think about whether or not they should be in the room in order to gain context as well as validate the context as being provided and give them clarity and peace of mind through the information that we've curated into these nine conversations that allows them to do what they do, especially in supporting this team to be successful.

[00:06:25] So thank you so much Evan for your question. For listeners who want to send in similar questions as a few ways that you can do it, if you go to our website and click the contact button there is an audio link that allows you to record your question.

[00:06:42] You can hit it at convergenced.fm slash contact or feel free to send us a direct message on any of the social platforms that we provide links to in the show notes.

[00:06:59] Fosturing and engage product organization and aligning them with the principles around lean, human center design and agile will more than likely lead to successful business outcomes for your organization.

[00:07:12] But getting started or getting unblocked can be hard. This podcast is brought to you by the player coaches over at integral. They help ambitious companies like you build amazing product teams and ship products in artificial intelligence cloud web and mobile listeners to the podcast can head on over to integral dot io slash convergence and get a free product success lab.

[00:07:39] During this session the integral team will facilitate a problem solving exercise that gives you clarity and confidence to solve a product design or engineering problem that's integral dot io slash convergence now back to the show.

[00:08:00] Now getting to the episode about technology lists and technology landscape there are a number of nuances I think to this conversation that's really important.

[00:08:12] The challenge that arises if you don't is inevitably you find out some kind of surprises way too late there's always going to be surprises the ones that we're trying to hit up are the ones that we could have avoided because we knew all the context required to surface the risks to minimize the chance of that surprise rising.

[00:08:32] So finding out too late or not having the right team is another one where there's not the right skill set on a team and we don't realize so much later as to why that team's not performing.

[00:08:45] There are dependencies not being ready where everyone thought that there's a third party API or SDK or another team within the organization that was going to provide a component in order to get us what we needed to go to market and we didn't have the right conversations with them.

[00:09:04] Early enough that we find out too late that there's a key part that's blocking our launch or success.

[00:09:12] So as always with this series talking about it together is a really important way to de-risk that and there is a risk of course of adding one more meeting to everyone's calendar.

[00:09:25] And we've curated this list of conversations to really get the most out of that meeting versus having unstructured conversations that don't necessarily have a direct correlation to outcomes or what you're looking to achieve.

[00:09:41] And this specific conversation around technology landscape I think really allows your technical team and your leaders on the team to have a chance to ask questions about what the expectations are.

[00:09:58] It gives them a chance to also validate the feasibility of what you're trying to achieve and that's a very important opinion given that these are the builders on the team that are going to get this done so that you can get the outcomes you're looking for from this component being launched.

[00:10:16] So knowing from them how likely they think the timelines and the integrations and the reliability and other pieces that we'll talk about gives you a very early heads up on whether this is something that you need to manage more aggressively and de-risk or whether it's something that is going to be a smooth sale and you can dedicate that energy toward something that maybe is more critical.

[00:10:42] So what are some of the things that come up in the technology landscape? One that gets us a lot are integrations and dependencies. If there's something that someone else is building that our team needs to use, it's important that we have a pretty good sense of what this is, what language is written in how it works, what kind of documentation we have.

[00:11:02] Is it already ready or not? There are oftentimes cases where for external parties, maybe smaller companies looking to get into a new customer. They may have market texture as they call it that doesn't necessarily reflect what the product actually does today and sometimes reflects what their intentions are for the future versions of their product and giving your team an opportunity to first of all at least know what they're going to be integrating number two.

[00:11:32] Getting them access to the right folks on that third-party team so they can integrate with maybe a sandbox or some kind of test area invalidate that what you're looking to do out of it is going to happen is really important.

[00:11:43] And that's because you have very little control over the roadmap prioritization and other operations at an external party compared to folks within your company.

[00:11:53] And if it's a really big part of what is needed and functionality that is going into the product, you run yourself a risk of that really important thing not being ready or not working as your team expected

[00:12:06] and allowing your team to run some spikes in other tests and gain confidence early makes it less of a risky surprise oriented integration.

[00:12:17] The same applies I would say for internal teams, especially at larger organizations if you are having to integrate with components of software or APIs that other parts of your company are building.

[00:12:30] It's important to understand from them where they're at today, where they intend on going, sharing with them the use case that you're looking to use it for that it's within the wheelhouse and that there are fewer surprises there.

[00:12:43] The second one is around the architecture. It's important that I think the business and technology folks are in the same room and talk about what is uncertain and what is certain.

[00:12:57] The uncertain things are usually the assumptions that are rooted in the innovation something new that you're trying something that you don't know as much about.

[00:13:05] And the certain things are stuff that you've done really well on and have high level of validation or confidence that it's not going to change too much.

[00:13:14] Putting my technology hat on, this information makes it really easy for me to architect the things that are certain for scale and the things that are uncertain for change.

[00:13:24] So that when the uncertain things may be changed, the cost of that change that you require in the product is really minimal, the delays and change are really minimal and you can iterate your way really quick as you respond to this new information that you gain about something that's uncertain.

[00:13:40] Other things are the level of scale and reliability and speed availability and performance, so the technical terms that you want.

[00:13:50] It's often that when we talk about availability and uptime of your application, folks will say that they need it up 100% of the time.

[00:13:59] Now the difference that goes into 100% versus 99% and 99.9% and 99.99% can be a tremendous amount of difference on your team.

[00:14:12] 100% is almost unachievable, most of the infrastructure like AWS or Google Cloud that we use don't support 100% availability.

[00:14:21] So there's no way that anything that sits on top of that can and having that conversation early and managing those expectations is good.

[00:14:28] Now the nines, as they call it, beyond that from the 99, are worthy of a really solid conversation.

[00:14:37] Sometimes if you're doing an internal launch or you're launching to a small market that is already trying to solve this problem,

[00:14:43] they may favor having access to your functionality a lot sooner than having everything perfectly ironed out to a highly available system because it saves them the effort and other things that can come into play.

[00:14:58] In other cases, that may not be the case. The same goes for performance and how fast your application responds.

[00:15:04] And having this conversation out in the open in terms of what's required is really critical and try your best not to say we need this to be as fast as possible.

[00:15:14] And get your hands dirty, get into the weeds a little bit more and speak with your team about what's required.

[00:15:21] Understand what the industry benchmarks are for your specific use cases so that you can make really smart decisions alongside your technical team.

[00:15:30] Whereby you're getting product out to market really fast in a very pragmatic way, but also building the architecture in a way that you can scale up improve performance as your gaining different points of validation or traction in the market and more customers and customer segments are being added.

[00:15:46] So that's a fine line and a fine balance, but it's worthy of having that conversation so that your engineering team knows whether they're over investing or under investing and things like that.

[00:15:59] Securities and other ones that come into mind here where believe it or not, there are apps that I have worked on and I know of certainly that don't necessarily prioritize encryption from the beginning.

[00:16:12] And this can be a okay decision initially depending on who you're launching to and how transparent you are about it, but over time that becomes a challenge and when that's going to become a challenge is specific on a team by team basis and require some level of critical thinking and having the conversation early really helps you with that.

[00:16:34] Tool set slang which isn't frameworks is the next one. For example, we have had teams that are using dot net because of some dependency or legacy code base they're working on and we ended up with a team that was primarily familiar with Java spring.

[00:16:52] And it's not to say that it's dead in the water and you can't move at integral we use techniques like pair programming and higher polyglots that are familiar with more than one language.

[00:17:04] And sooner than later you have a team that's familiar with the second language when they've paired on this language and are able to apply those fundamentals that they know from the language of familiar with to a new tool kit in language.

[00:17:16] And that requires an open conversation about what kind of language we're using in order to make sure that we have the right team or make sure that we have enough team time to do that knowledge transfer and close those skill gaps out so that we can get as quickly as possible to a predictable speed and velocity of delivery.

[00:17:38] I mentioned another one in there which was legacy code base and this one similar to integrations and dependencies. If there's a part of the code base that your team has to use that someone else is already written.

[00:17:49] It is for whatever reason very natural for folks to assume that if software engineer a wrote it in the certain language and software engineer b knows the same language that they should be able to pick it up and run with it.

[00:18:02] If only that were the case context changes the teams change and sometimes that legacy code can be pretty difficult to use depending on who wrote it when it was written and what kind of principles and coding standards were applied.

[00:18:16] And making sure this team knows is early getting them access to that code base allows you to make that decision of whether you're going to continue using that code base.

[00:18:25] If you're going to rewrite it or refactor it, what kind of pattern you're going to use for refactoring it and having a conversation that gives you a window into how risk your not it is.

[00:18:36] How quickly this can all get done as well as how much additional effort or how much you need to get involved in order to help the team do risk.

[00:18:48] So if you're using a legacy code base, make sure that the team knows make sure they have access to that code base is quickly as possible.

[00:18:55] There are cases when they don't and that's a whole different set of questions that we can maybe get to at different episode.

[00:19:02] The last thing I think from a technology landscape that is a little bit more nuanced and specific to mobile or maybe embedded devices is talking about what kind of target devices you want it to be compatible on.

[00:19:14] And this could on mobile change the way that we test for screen size or operating system compatibility in the case of Android specifically, things can change a fair amount depending on even the manufacturer where you have the application working on a Samsung device and then you get an HTC device maybe and it doesn't quite work as well.

[00:19:37] So make sure that you form an opinion early in terms of what your priority target devices are.

[00:19:45] There's a lot of information available online in terms of what kind of devices tend to have the market share.

[00:19:52] You also likely have this in the analytics if you already have a website that can help you inform what devices you want to make sure to be super compatible with.

[00:20:01] And then the last one I think is super important is around testing principles and more testing tends to generally be good.

[00:20:09] That being said, there is a minimum effective dose depending on the maturity of the product and who you're launching this product out to that needs to come into play and that conversation really helps with making sure once again that your team isn't over investing or under investing compared to what you would expect as maybe a product person or a business person.

[00:20:31] And having the conversation once again just allows you to rumble through what the right level of investment is compared to what you're up against and where you're going next.

[00:20:43] So those are some of the things that I hope you will consider and have a conversation without loud with your team.

[00:20:50] Make sure you get the right stakeholders in there and do risk the technology landscape on the delivery of your product.

[00:20:57] Thank you once again for listening. We will be back next Tuesday with another episode in the meantime don't forget to go back and check out the episode from April 23rd that has all of the nine conversations in a brief format and look forward to the remaining four conversations as you hit subscribe.

[00:21:25] Thank you for joining me on the convergence podcast today. Subscribe to the convergence podcast on apple podcast Spotify, YouTube or wherever you get your content.

[00:21:37] If you're listening and found this helpful please give us a five star review and if you're watching on YouTube hit that like button and tell me what you think about what you heard today.