7/9 Critical Conversations You've Forgotten to Have With Your Team: What are the biggest assumptions we're making? PART 1

[00:00:00] Welcome to the Convergence Podcast. I'm your host, Ashok Sivanand.

[00:00:05] Ashok Sivanand So it's kind of counterintuitive because sometimes we hear we don't have time to experiment. We have too many things that we need to build. And really, we were able to use that building to increase confidence and ultimately ensure that the next three months we're going to be like for a good result.

[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:38] Welcome back, folks. Today, I'm joined by Bailey O'Shea to continue our series of the nine crucial conversations that we believe every product team must have.

[00:00:48] Now, my team at Integral and I have helped numerous product teams at startups as well as Fortune 50 enterprises with improving the way they collaborate to prioritize, design, and ship delightful products.

[00:01:01] In that time, we have found ourselves retrofitting conversations that the team might have forgotten to have and ends up causing them expensive downstream issues in order to help them ship more delightful products in a better process.

[00:01:16] So what we did was put together a list of the nine most commonly occurring of those conversations, especially the ones that tended to have the most impact on the team if we were able to fix it.

[00:01:28] And today is the first of a two part series about conversation number seven.

[00:01:33] What assumptions are we making as a team?

[00:01:37] Admittedly, a conversation about assumptions could sound quite ordinary given how commonly we use the term.

[00:01:44] That being said, as we'll discuss on the episode, it is a very common trap that we all, myself included, fall into.

[00:01:52] And I believe that being intentional about understanding the assumptions in the system and on a team is extremely helpful at helping avoid those downstream losses, while also helping your team be more engaged, nimble, and go a lot faster at adding value to both your business as well as your customer.

[00:02:12] My bet.

[00:02:15] My guest today, Bailey is the director of product at Trans Impact, where they are solving important problems in the logistics space.

[00:02:24] Prior to that, Bailey and I worked together at Integral for over five years, where I had the pleasure of working alongside her to help customer executives with organizing their product teams, prioritizing their product roadmaps, and delivering high quality products.

[00:02:42] Now, if you're curious about the other crucial conversations like this one, check out the summary episode that we did from April 23rd, 2024, where we talk about all nine of the conversations at a really high level.

[00:02:56] There's also subsequent episodes where we do these deep dives like this one.

[00:03:00] So make sure to subscribe to the podcast to be notified when we release part two of this crucial conversation, as well as the remaining deep dives and facilitation techniques for conversations eight and nine.

[00:03:15] Be sure to also check the show notes for a link to an ebook that we compiled about these crucial conversations that can help you with facilitation.

[00:03:24] Subscribe to the podcast to get future episodes as soon as they're published.

[00:03:28] If you find this helpful, give the podcast a five star rating on your podcast app or hit that like button on YouTube.

[00:03:36] Here is Bailey and I.

[00:03:42] Bailey, welcome back.

[00:03:44] Thanks. Good to be back. How are you?

[00:03:46] I'm doing great and I'm excited for you to join us back to talk about this crucial conversation.

[00:03:53] Just given, I think, how much difference a team can make by going through this conversation around what are the assumptions we're making.

[00:04:04] You and I have, of course, facilitated our way through and fought the good fight with many product teams, product teams leader trying to interject this conversation or retrofit it.

[00:04:14] So maybe for the audience, I'll put you on the spot and ask you what what's an assumption?

[00:04:21] So an assumption is kind of what must be true in order for something to happen.

[00:04:31] So it is something that you are based on your experience or based on your goals you're assuming is the case.

[00:04:40] And it's something that since elementary school, our teachers have tried to teach us with various mnemonics around how to not assume things and how it leads to downstream conflict.

[00:04:51] But it's also just part of human nature, right?

[00:04:53] We have to make assumptions in order to make progress on things, whether it's assumptions on things that must be true for us to get to work on time today or for our product initiative to be successful.

[00:05:06] And at the same time, I think it's really hard for us to balance both making those assumptions and making progress along those assumptions while also being mindful of what assumptions we are carrying and which ones we feel like are more or less risky in the various assumptions that we have.

[00:05:28] And a lot of the time, you know, in most cases, any initiative has a destination, whether we're trying to get to work, whether we're trying to get a new market with our product or generate X amount of revenue with our product.

[00:05:43] We have some kind of plan to get there on how we're going to drive there or what kind of features or customer actions or employee enablements happen from a product.

[00:05:56] And then there's some way that, oh, ideally, we are being intentional about telling whether or not we've arrived there at the destination with that product investment.

[00:06:07] So what have you seen here?

[00:06:09] Before kind of we get into the space of like assumptions as it relates to like business for product development, something I just want to share is that it's like many assumptions are subconscious.

[00:06:21] It is based on your experience and your knowledge, your unique perspective.

[00:06:27] And it is a muscle that once you start building that up and becoming more aware of the assumptions you're making, it's easier to articulate those to other people.

[00:06:36] And it's also easier to spot when somebody else is making an assumption based on maybe some of the leaps that they're taking in conversation around this is a potential solution to the problem.

[00:06:47] You know, when anybody suggests a potential solution to the problem, there's assumptions in their head as to why that's the case.

[00:06:53] So those are kind of good indicators to spot that.

[00:06:56] I think that's really important to clarify because there might be audience members out there thinking, are we actually doing a conversation about assumptions?

[00:07:04] Why does it matter so much?

[00:07:07] And I think that sort of cognitive bias that we have that leads us to forgetting what you just mentioned is really why we end up seeing so many losses or pain points or friction points when we do product development.

[00:07:22] Because we didn't turn over a rock around an important assumption.

[00:07:25] So I think for me, it's also, you know, hey, we are doing our best and we might be able to do a little bit more to de-risk where we're getting and making sure we get there.

[00:07:34] But there's so many things that we could do to de-risk and help enable and make sure that we get there that it's hard to prioritize what it is that we're doing that de-risking or experimenting around.

[00:07:48] And there's another place that I think having this conversation can really help everyone from the executives all the way through to the delivery team.

[00:07:58] And so what's a story that you might use to convince yourself that it's worth having the assumptions conversation or convincing someone else that comes to mind from your past?

[00:08:09] Yeah.

[00:08:10] And before I get in the story, I want to gate it a little bit that like before we talk about assumptions, like there's got to be a goal or a thing you're looking at because you're it's it's to save time.

[00:08:22] Ultimately, it's to save the mental load. It's you're making assumptions to get faster, to get there faster.

[00:08:29] You need to have a plan in mind to get to that goal or that destination.

[00:08:34] That plan could be features. It could be actions. It could be some level of confidence or risk tolerance.

[00:08:42] And then also.

[00:08:44] You want some indicator or metric that tells you that you've arrived at that goal.

[00:08:50] So a story that comes to mind for me was when we were working together, we were working with a loan company and loan processing was the problem at the time.

[00:09:01] And their goal was to minimize that problem.

[00:09:04] So when you pull apart the problem, there were errors and delays in that processing in that processing environment that were causing downstream issues for the business.

[00:09:15] Those issues were customer experience related, partnership related, ultimately impacting their profitability because of errors and delays.

[00:09:27] Sales was slowing down and also the cost of serving customers were going up because of those issues.

[00:09:35] When we were kicking off that work, you know, the biggest assumption that we were making is we could de-risk this through automating the process.

[00:09:45] Like we could improve these errors and we could ultimately impact that problem that's hitting the bottom line the more we automate.

[00:09:56] Now, a way that we could have gone about that is let's start automating everything.

[00:10:00] The issue with that is it's really hard to measure which elements are actually moving the needle versus what might just be a byproduct or correlated to the problem.

[00:10:11] And the risk of that is that you're spending time on things that actually don't matter.

[00:10:16] And by trying to solve it all at once.

[00:10:20] So what we did was we tried to put a fence around a specific problem and we wanted to automate a specific calculation that the loan process was loan processors were making in order to get the document to the next step of the process.

[00:10:38] We noticed there's a lot of manual work there with manual work always increases your propensity for error.

[00:10:45] Also, time invested.

[00:10:47] Also, training time invested so people know how to do it.

[00:10:52] So ultimately, we took a couple of days and just created a prototype and started shopping that around and putting those calculations through the prototype to validate, do we have confidence in this automation?

[00:11:05] And also then putting that in the hands of the loan processors themselves to say, do you have confidence in it?

[00:11:11] And is it saving you time?

[00:11:14] Ultimately, we did not find any errors when we automated that specific element.

[00:11:19] So that increased the confidence of both the loan processors using the tool, but also the business to say, we want to invest more time in automating more of this now.

[00:11:28] We feel good about it being like a parody of the outcomes that we are doing manually.

[00:11:34] But also, it ended up saving time as a byproduct, saving close to two minutes per transaction.

[00:11:42] So really, the big takeaway for me was putting the organization into a learning mindset.

[00:11:51] We were able to iterate faster on those business outcomes.

[00:11:57] And it gave the team permission to experiment.

[00:11:59] So it's kind of counterintuitive because sometimes we hear we don't have time to experiment.

[00:12:03] We have too many things that we need to build.

[00:12:05] And really, we were able to use that building to increase confidence and ultimately ensure that the next three months we're going to be for a good result.

[00:12:15] Yeah. So this is an important business problem where I recall their partnerships were at risk with some of the lending organizations they were working with.

[00:12:23] Their customers were kind of frustrated.

[00:12:25] And a lot of it came down to, hey, we got to fix this manual error that's coming from our team.

[00:12:32] And we know that there is a high level of variance, which I think is an important product instinct thing of when you see certain customers or certain users doing things the way you intend.

[00:12:43] And then a long bell curve of folks who do it with high level of variance.

[00:12:48] Automation or having a software process is one way to kind of reduce the variance and thereby reduce error.

[00:12:53] And that was kind of our initial hunch because when we prioritize even any investment because it was a big business problem that the executives were wanting to de-risk and technology was one of the avenues.

[00:13:05] And then I love how we I think it was the process went from 10 minutes down to two minutes.

[00:13:11] Right. We saved like 80 percent of the time, if I recall.

[00:13:15] Yeah.

[00:13:15] And so it was a lot faster, too, on top of the fact that there was way less variance in terms of the errors.

[00:13:23] And so not only were customers a lot happier, their partnerships were de-risked.

[00:13:29] And their internal team could just handle way more volume than they previously could at a time when this company was really bursting at the seams when they were really hit up with a ton of demand and figuring out different ways to build a platform for scale, really.

[00:13:45] Right. So I'm curious, how did.

[00:13:50] How did we figure out which experiments to do first in that case?

[00:13:55] Yeah. So this was in our discovery frame when we were trying to understand the scope of the problem and what was impacting it the most.

[00:14:06] We did an assumptions exercise.

[00:14:08] So as a group, you had sales, you had marketing, you had loan processing, you had every other element of the business in the room.

[00:14:15] And we kind of did a let's all sit with this goal of wanting to improve the process, reduce errors, save time.

[00:14:23] And from your lens, what must be true in order for that to happen?

[00:14:29] Like in order for us to actually produce those errors.

[00:14:31] And everybody took, you know, 10 minutes to themselves, wrote things down, one thing for sticky, and we just started sharing it with each other.

[00:14:39] And what what we were that allowed the room to do is understand everybody's unique perspective, but also for us to then, hey, six people in this room share this perspective and start to prioritize these things based on perceived risk to the business.

[00:14:58] If we didn't, you know, validate it sooner.

[00:15:05] Fostering an engaged product organization and aligning them with the principles around lean, human centered design, and agile will more than likely lead to successful business outcomes for your organization.

[00:15:18] But getting started or getting unblocked can be hard.

[00:15:21] This podcast is brought to you by the player coaches over at Integral.

[00:15:25] They help ambitious companies like you build amazing product teams and ship products in artificial intelligence, cloud, web, and mobile.

[00:15:36] Listeners to the podcast can head on over to integral.io slash convergence and get a free product success lab.

[00:15:45] 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.

[00:15:56] That's integral.io slash convergence.

[00:16:00] Now back to the show.

[00:16:02] The other thing that teams tend to shy away from is bringing in folks from other departments in here.

[00:16:14] So we had sales and marketing ideating alongside product team members.

[00:16:19] And this way you get to have a, you know, I hate to use the term cross-functional because it's very jargony, but across your organization, there are folks who know what other people on the team are worried about.

[00:16:32] And not only can you prioritize helping your team members on things that you have now identified are really big concerns that you may not have seen.

[00:16:42] But I think on the flip side, you're also able to sort of put your team members' minds at ease around things that you may have a much higher sense of certainty around that maybe they feel uncertainty.

[00:16:57] Actually, a story that comes to mind for me here is also in the auto space or in the auto lending-ish space where we worked for an automotive OEM who was looking to experiment with their business models around how they sold cars.

[00:17:14] And they had this off lease.

[00:17:17] So whenever you go lease a vehicle for two or three years, it's on them to figure out how to get that car back to auction and it gets sold as a, you know, as a pre-owned vehicle, right?

[00:17:29] And so they had that problem that they wondered if they can solve a little bit more.

[00:17:34] And then more strategically, they saw that their market was shifting away from maybe vehicle ownership.

[00:17:39] This was in the 2016 era where we felt like maybe vehicle ownership was going to change dramatically with autonomous vehicles, Uber and Lyft, scooters everywhere.

[00:17:50] And how we get from point A to point B was going to change.

[00:17:53] And they noticed that their consumer millennials were wanting to own fewer things and have more experiences.

[00:18:03] And so the subscription model and things as a service were sort of coming into the foray and they wanted to de-risk their overall business from these changes.

[00:18:13] And so they came up with an idea for a monthly subscription, kind of all-in model, like you would rent something, like you would rent your Netflix subscription where you don't have to worry about insurance or maintenance or any of those things or long-term commitment.

[00:18:28] And you could do 30 days at a time where everything was sort of taking care of you, especially for folks who didn't care about necessarily owning a new car.

[00:18:36] And so there was a business model that they had assumptions around.

[00:18:39] There was a target customer that we realized were a top assumption.

[00:18:45] And then they were also unsure about what level of investment to put into play for something that could be a huge game changer for their business model in the future, but at the same time could maybe not have any impact either.

[00:19:02] And not knowing what level of investment made sense.

[00:19:05] So what we did was we helped them with, number one, doing research across all those three.

[00:19:11] There were way more assumptions that we were able to ideate, but we were able to sort of mitigate those assumptions from becoming risks right in the room where, as I was mentioning around the payments, one of the executives who was less on the technical side would not stop talking about payments.

[00:19:28] Turns out they had a bad experience with a previous application they worked on where there was a lot of other things that worked right, but the app had really buggy payments, which I've been part of as well, where didn't necessarily scale as the customer demanded.

[00:19:44] And they ended up losing a ton of revenue and profit because the app tended to crash in the tech checkout page.

[00:19:50] And in this case, a lot had changed since that for that executive.

[00:19:56] And we were going to use Stripe checkout, which is one of the top three most resilient checkout options that you have from a payment services provider.

[00:20:08] And this executive didn't know much about Stripe.

[00:20:10] They didn't know about the level of confidence.

[00:20:12] But hearing from their engineering counterpart that, hey, this is one thing that I'll put my name on.

[00:20:17] We don't have to worry about because all of these companies use it.

[00:20:20] I'm excited.

[00:20:20] I've used it before.

[00:20:21] It will work, especially for the low volume that we're initially going to work with.

[00:20:27] And here's my scalability plan.

[00:20:29] And so that executive who was really worried about payments had their mind at ease and they could bring themselves to helping the team and the initiative with something that was actually a risk.

[00:20:40] Something that collectively we had an uncertainty around and we needed to bring our best selves and hope for good luck plus really disciplined experimentation to get through.

[00:20:49] So going back to your point about making sure everyone's in the room, that's hard to do, I know, because folks are in different departments and you're not used to collaborating with each other depending on the type of org you work in.

[00:21:01] Yeah.

[00:21:02] But this is definitely one of those nine times that you want to invest some level of social capital you have to bring the right folks in the room so that you can have this conversation out in the open and the different departments can come together to feel more confident about something or put in the right amount of effort in the areas you're not as confident to de-risk things and learn more and ideally improve the confidence levels.

[00:21:28] Yeah, I love that you're talking about it being collaborative because that's the purpose of it.

[00:21:33] So if you're in an organization, you're an engineer, you're a PM and you're like, man, I just feel like I'm doing what everybody tells me to do.

[00:21:40] I have a directive and I am showing up here and I'm just doing it.

[00:21:43] And you're trying to get out of that mentality with your team, like using the word assumptions is great in terms of introducing that level of conversation.

[00:21:55] It will shed light into, you know, if you want to collaborate better with engineering, ask them what their assumptions are behind like this goal next quarter.

[00:22:04] Like what are the technology assumptions that they're thinking about that they have to make?

[00:22:09] Because you pull that apart.

[00:22:11] Now you've got a few new spikes in the backlog and those spikes come from the engineer's mindset.

[00:22:16] They're not being told to do.

[00:22:17] And so it's all about like inviting everybody's unique perspective in the room to help tamper.

[00:22:24] Maybe somebody else is like, you know, I don't know everything about technology stack, but somebody who does can help alleviate that risk for me.

[00:22:35] So to your point, I'm bringing in my like I'm focused on the right things and as the group is focused on the right things that we collectively don't know.

[00:22:46] And you mentioned spikes there.

[00:22:48] It's one of the form of experiments.

[00:22:51] And in that story that I mentioned around that executive, if there wasn't a level of trust that either that engineering lead had with the solution of Stripe, or if there wasn't a level of trust between the business lead and that engineering lead,

[00:23:05] then that's a good way to short circuit it saying, hey, you know what, I can put together a quick prototype to make quick and dirty and my team can do it in a matter of half a day where we're going to push through, you know, a thousand requests or 10,000 requests through this API and see what it does and at what point it crashes.

[00:23:22] In case we don't trust the documentation.

[00:23:25] Now, in that case, we were using Stripe and Stripe was extremely credible by that point.

[00:23:30] And most of the engineering folks had heard of Stripe, maybe used it, maybe had been successful with it before.

[00:23:36] Or you may be working with an integration that is from a startup or someone that doesn't necessarily have the same level of credibility.

[00:23:44] So running that experiment, in this case, a technical spike to de-risk that is essentially what we're talking about, where a worry that could be sitting on this executive's mind for months on end can be put at ease.

[00:23:57] Or if they were right and scale could not be handled by the third party integration, you're finding out in the first week or two, knowing that it's one of the biggest things you're worried about.

[00:24:10] And it's something that you're putting the two or three days to run that experiment against, where you have enough time now between whenever you find out to when you're going to launch to find a mitigation.

[00:24:23] Whether it's building some kind of wrapper around this integration, whether it's finding alternatives, whether it's collaborating, whatever those options are.

[00:24:31] Identifying the riskiest things early through being intentional around the assumptions is the way that you're not only going to go faster, but also buy yourself the most amount of time and optionality in the future for when things go wrong.

[00:24:49] Thanks a lot for listening, everyone.

[00:24:52] Stay tuned for the second part of this crucial conversation about assumptions.

[00:24:56] When Bailey and I returned to talk about how managing your assumptions really makes it a lot easier to thread the needle around that famous adage, plans are useless, but planning is indispensable.

[00:25:10] We talk about the benefits of giving everyone on the product team permission to poke holes in the system and thereby identify assumptions.

[00:25:21] The various types of assumptions that tend to be most useful in unearthing.

[00:25:26] How to facilitate a great assumptions generation workshop.

[00:25:30] And tactics on how to get started right away, whether it's by yourself or with your team, using a virtual or in-person whiteboard and sticky notes.

[00:25:40] Hope y'all have a great week and I look forward to catching y'all next Tuesday.

[00:25:51] Thank you for joining me on the Convergence podcast today.

[00:25:54] Subscribe to the Convergence podcast on Apple podcast, Spotify, YouTube, or wherever you get your content.

[00:26:03] If you're listening and found this helpful, please give us a five-star review.

[00:26:07] And if you're watching on YouTube, hit that like button and tell me what you think about what you heard today.