The three ways that I thought of really all revolve around making life insurance more accessible for people. 

1) For individuals, life insurance is typically a multi-week long process that requires some doctor's visits. And so it's a really big barrier for people to actually go and acquire it. And so our platform cuts that down to just a couple of minutes and basically an instant decision. So that's one kind of with direct individuals.

2) Through empowering life insurance agents. So, they are really a key, critical part of the process for people to kind of navigate and figure out really what is going to work for them and what their needs are. And so we also use our platform to empower those agents, to do their job faster and easier.

3) Using our platform to enable other life insurance carriers to be able to sell term life more efficiently. Term-life insurance is typically a pretty low margin business, but it's something that people really want and need, and so we've been able to take our platform and make it available to life insurance carriers so that they can use it to sell life insurance faster in the same way.

1) Offering life insurance carriers our platform. That was basically what kind of my last year it looked like. It was taking the Bestow platform that we had built to sell directly to customers, and reorienting it, and evolving it, to be able to be the software as a service offering. And so there was just a lot of alignment and coordination across pretty much every team at bestow to take this one way that we knew of working with things, and the way that we thought of our platform, and kind of shifting it from a perspective of not just something that enables us to sell to our customers, but to be able to enable others to sell to their customers. And so definitely learned a lot of lessons just around giving people the right context, helping people understand why their pieces matter to this big, huge, whole of a project. 

2) Scaling the Bestow product team. So when I joined Bestow, about two and a half years ago, we had a team of about four or five product managers. And now, our team is right around 20 now. And, that's just been a lot of learning around figuring out how to get all these products managers, and different product areas, to coordinate with each other, understanding the dependencies between them. How we can enable each other to ship faster and not get in each other's way as we're trying to get products out to market? Just learning how to coordinate with that group and to do it in a way that we actually enable each other instead of just have to work around each other has also been, I think, definitely a hard problem to solve, and something that we've been working on.

3) I'm sure a lot of people can relate to this, but I think especially the last two years, working from home. For me, I've got three young kids, from nine years old to three years old, and working from home, whether they had school lockdowns or when it's in the summer and they're at home, has definitely taught me a lot about just flexibility between work and life, where it's not as straightforward as just leaving, going to an office, and coming back a couple of hours later. But definitely learning to have more flexibility with that and give more grace to myself and to others.

1) What's just one thing that I can do, and feel like I've checked off, to start moving in that direction? So I was thinking about that from kind of a couple of different angles, for myself and others. One of the first things that came to mind is whenever I am getting started on somewhat of an ambiguous effort, or I don't really know kind of where to start with something, kind of the  blank slate problem, is just identifying something that I can do to make just even a little bit of progress in the direction that I'm trying to go. Even if it maybe doesn't totally solve the problem that I'm trying to go for, it doesn't provide all the answers, I find just getting momentum on it is really helpful. So I always ask myself, “Okay, what's just one thing that I can do, and feel like I've checked off, to start moving in that direction?”

2) What is something that feels harder than it should be?  A question I really like to ask my teams and coworkers as we're working through things, and looking for ways to improve things, is asking, “What is something that feels harder than it should be?” And so, I think it's a really good way to expose areas that maybe you've lived with in your product or your process, that some circumstances have changed, and you don't really have to live with that anymore, and you can find ways to improve it. Or, it just allows you to have some reflection and some areas that maybe have been difficult to figure out and untangle, and people have kind of avoided it, but it's an opportunity to really look at it and say,  “Are we okay with it being this hard? Or is it hard for a reason that we can actually change and improve?”

3) What differentiates you or makes you more effective than other people in your role? One that I really like to ask others, just in terms of learning from them, and especially when I'm interviewing a product manager candidate is asking, “What differentiates you or makes you more effective than other people in your role?” So whether you're a product manager, if it's like other product managers, or engineer, and things like that, I think it's a really interesting question because I don't think a lot of people enjoy talking too much about the best parts about themselves, so it gives them an opportunity to reflect on that. But it also opens up, shows, what's important to them, and what they really like to focus on.

1) Get the problem as visual as possible and as quickly as possible. The first thing that I thought, and this is probably a whole bucket of mental models, but whenever I'm trying to work through something or figure out how things relate to each other is I try to get the problem as visual as possible and as quickly as possible. And so whether that's using my whiteboard and just writing it out or getting some sort of online whiteboard like Miro and just trying to map something out with sticky notes. I find that being able to visualize the problem space can help you to uncover patterns and figure out how things relate to each other differently than you might, even if you were writing about the problem, or if you were trying to explain it to somebody. And so, I know not everybody's a visual thinker, but it's almost always the first tool that I go to when I'm trying to understand kind of the landscape of something.

2) LNO framework (leverage, neutral, overhead). Another thing that I like to use, and this is really just for prioritizing my own tasks and things that I need to get done, is something that I've heard of called the LNO framework, which stands for leverage, neutral and overhead. Basically, it's a way to kind of look at the things that you need to do and understand of how much effort and time you need to put into any one of those tasks. They're all things that probably need to get done to some degree, but basically what it allows you to do is, especially if you have any kind of perfectionist tendencies, it basically allows you to really put the most effort into the things that you're going to get the most out of. So, if you can look at a task and say, “Hey, if I get this task done, it's going to provide a lot of leverage. And, either it's going to allow me to take a big leap in this problem that I'm working through, or maybe it's going to enable others to do their work better.” Then you see that as a leverage thing, and that's something that you really want to spend  a good amount of time on to get right. But, if you're looking at something that's neutral, or even something that's overhead, those are things that you can allow yourself to maybe not put in 100% percent of your best effort into, just because there's not going to be a huge payoff out of it, and you can kind of allow yourself to just check off that box and move past it. 

3) Thinking in probabilities versus thinking in right and wrong. Another one is really just thinking in probabilities versus thinking in right and wrong, especially when it comes to forecasting or trying to predict what's going to happen. Particularly if you're bringing a new product to market, or you're trying to launch something, and you're trying to understand what the risks might be involved. I find a lot of times it's easy to say, “Oh, I think it's likely this is going to happen. Or, I think it's unlikely this is going to happen.” But really, it makes it hard to have a conversation around it, and so if you can actually put probabilities to things, even if it's just something that you pull out of thin air, and you say, “Well, I think we're 70% likely to succeed in this effort.” It creates an opportunity for a conversation, for somebody to say, “Well, what can we do to get that closer to a 100%? Or, are we okay with 70%? And maybe that's what we want to live with.”

1) The written problem statement. So I think I mentioned writing earlier as opposed to visualizing things, but I do actually really believe in the written problem statement. Both in terms of the person who's trying to define what the problem statement is, because I find that when you have to write out the problem, it really requires you to understand it fully, and you start to see just some of your own holes in the way that you've assessed it, or some areas that you need to spend some more time digging into, and then it also allows people who are reviewing it to really spend some time interpreting it, understanding what you meant by it, maybe catching things that you assumed that everybody else was aligned on, but you need to find some alignment there. And so I think having those written problem statements is super important.

2) Along with that, creating time within meetings for silent reading of those problem statements. And so, everybody's busy, not everybody has a time to do pre-read, spend time on the pre-reads before a meeting, but even if you just take 5-10 minutes out of your 30 minute meetings, so that everybody can fully read and digest it, it can really make that discussion more effective. 

3) Working on visiontypes. The other thing that we've been experimenting with lately at Bestow is working on visiontypes. We define those as basically really fuzzy, future-looking prototypes for things we're trying to wrap our heads around, but we really don't have a defined scope of what it's going to look like. We found that doing this really allows us to create something tangible that we can have a conversation around and talk through. Even if it doesn't cover all of the boxes, or it doesn't check all of the regulatory issues that we might think need to think about, they kind of provide just this visual flow. Someone can interact with, and talk through, and I think it's a lot easier to get in the mindset of, “Is this going to work? Or, is this in the direction that we want to go even more so than a set of requirements, my written requirements, might be able to indicate?” 

4) What would happen if we waited three months to do this or nine months to do this? Asking a question for when you're working on prioritization of things, which is, “What would happen if we waited three months to do this or nine months to do this?” It's a more specific way of asking, “Why do we need to do this now?” Thinking about the future state, and somebody says, “Oh, we really need to do something. Or this is a really big opportunity.” Projecting into, “Well, what if we didn't have this in three months or nine months? Would this really still be an issue, is this an issue that we can live with? Is it something that maybe isn't as important as we thought it was?” And so, it can really help to actually quantify the opportunity and the problem that you're talking about.

This is a great question. I really liked the chance just to chat about people that I've really enjoyed working with. So, I had a few people in mind. 

1) Kaushik Sahoo. He's an engineering manager that I used to work with, and despite being in the engineering organization, he's just got such a great product perspective on what is really needed to ship something. He and I have worked on some great things and his partnership has just been crucial to be able to get those things out the door.

2) Ben Newell. Who's right now Senior Director of Stitch Fix. And I haven't ever actually worked with Ben, but he and I have been in a lot of the same product circles. And I've gotten to watch a lot of great talks that he's given and he just has so many great insights on how to do product well, and how to run product teams, that I've always just looked up to the things that he's shared with that. 

3) Sylvia Cento. One person from my own company is Sylvia Cento. She's the Director of Technical Program Management at Bestow, and she has just been critical to so many of the things that we've launched at Bestow recently. She just has an incredible ability to get people together and helps you identify blockers and plans of attack to break those things down and actually get the things out the door that we're trying to ship.