Product-Market Fit with Chris Duncalf

006 - GAT Podcast: Force Multiplier - Michael Jelen & Chris Duncalf Discuss Product-Market Fit

MJ 00:00 Hi, everyone. This is Michael Jelen, and welcome to the BRG Global Applied Technology podcast. The GAT team, as we call ourselves, is a globally distributed team of software engineers, data scientists, graphic designers, and industry experts who serve clients through our BRG DRIVETM analytics platform. We're helping some of the world's largest and most innovative companies and governments transform data into actionable insights.

Today, we have a return guest, Chris Duncalf, from the BRG GAT team. Chris has twenty-five years of experience in healthcare informatics from both the private and public sectors. Today, he'll be diving a bit deeper into the product process, understanding how we achieve product-market fit, and how to stay focused on well-defined problems despite our consulting experience pulling us towards each and every client need that's thrown at us. As always, if you have any questions or feedback please drop us a line at gat@thinkbrg.com. And, with that, please enjoy this conversation with Chris.

Listen to Michael and Chris discuss “Methodology for Assessing Information Maturity”

CD 00:54 Hello, Michael.

MJ 00:55 Hey, Chris. How's it going?

CD 00:57 Not too bad at all. Thanks. How are things going with you?

MJ 01:00 Excellent. Well, thanks for making time to speak with me today. This is going to be a bit of a follow-on from a previous discussion that I had with Octavia about our overall product process. I think she did a good job summarizing how we approach things from the very beginning of the product process through the end. But, as you know, things pop up. There's some challenges. And so today, I was hoping with you we could do a little bit more of a deep dive into some of those challenges and pitfalls, lessons learned, and ways that we can avoid them in the future.

CD 01:31 Absolutely. Yeah. That would be great. Sounds like some time well spent.

MJ 01:35 Perfect. Well, if you'd like, maybe you could just start off by providing a little bit of context about the product process. Maybe summarize some of the major points. And then we'll go from there and jump into some of the things that we think are important to keep in mind.

CD 01:47 Yeah. Absolutely. So, I mean, we've essentially implemented a product process that consists of eight stages. So one of those stages is our direct. And that wraps around the whole process. So that's direct and goes through each of these stages to ensure we're? undertaking the right activities and getting the desired outcomes and outputs, really. But within that, we're essentially looking at seven stages. So we have a discover stage, which is all about ideation and very much developed so that anyone could bring any idea to the table. Very quick process to fill an innovation canvas, get an idea on the table that's then up for discussion to understand whether it's something we take forward and move to the next stage.

After that, we've got define and design, which essentially encapsulate defining the real problem—the job to be done, if you like—a quick profile of the competition to start with, looking at potential user personas, defining some of those features and functions. And the design phase would be starting to pull that together into some wireframing or some early designs. At each of these stages, we do have a gated checkpoint at the end, where we get together as a product group to decide whether we'll be taking these ideas forward. All of those sit essentially in our process to the left of what we're defining as a green line, which really is our green line to start real development. So that wireframing and prototyping sits to the left of that green line, but this is before we expend any real effort, real resource in actually putting that product together. Have we got the right thing? Are we taking a product to market that there actually is a real need for?

So then to the right of that line, we get into develop, deliver, drive, and decommission. So those are the four stages that sit over there. So very much about creating the product, launching it into the market, driving it with an engaged user base, and adding more context, adding more features, functions. Then ultimately a sunset strategy should we need it, where we need it on those types of products. So something that basically covers the entire product lifecycle but gives us all the necessary checkpoints instead, just to hold us accountable, really.

MJ 03:55 Gotcha. Perfect. So that first set of three—discover, define, and design—if we were to start there, is it safe to say that the main objective of those three phases is really to understand whether or not the idea that we're talking about has a good product-market fit? Is that the main objective?

CD 04:13 It is. Absolutely. There's a number of reasons why you'd want to do that, not least the bottom line and not taking products to market that nobody wants. But it is exactly that. We're open to all ideas, of course, coming to the table, whether they're from true innovators within our own organization or coming from customer pain points. Well, those three stages are absolutely about drilling down into that level of data and understanding the actual need that the market, let's say, the competition, and ensuring that we're meeting a need that's out there really, and that people are looking to actually either improve upon or actually solve, should it not have been solved already.

MJ 04:55 Gotcha. So what would be some of the things we want to keep in mind at that point? And of course, if you have any examples or thoughts from things that we've actually experienced, feel free to mention those. But yeah, what are some of the pitfalls in ensuring that there's a good product-market fit?

CD 05:13 So I think that to start with—and it seems like an obvious one, doesn't it? But I think talking to the customers that are out there is perhaps the most obvious thing to say, but actually one of the hardest things to do really. You want to be meeting a real need that exists. I think there are organizations out there that they're going to push innovation and technologies, such that they create a market for a product that didn't exist; that the rest of us didn't even know we needed. For example, who would have imagined, a good few years ago, that we'd be carrying around our entire music collection stored on our phone? Or better still, we don't even own any music collection now, because we can stream it all. It's highly unlikely that idea would have come from a general consumer in the street.

But likewise, you can't take that to extremes and just rely on your own thoughts of what you think people want, because the vast majority of organizations out there, ourselves included, are looking to solve problems that exist either in a better way or faster way or more technologically advanced way. So finding that balance by actually talking to your existing customers, if you already have them, or trying to get potential customers to the table. And that is the tricky one, but it is very much an innovation-versus-value argument. We want to avoid creating technology looking for a problem to solve, of course.

So, I mean, one of the biggest challenges, first, is if you're not, well, that customer base, if this isn't about adding new features to an existing product, you're trying to solve a new problem, getting those customers to take time to sit and talk to you. There are organizations, there's companies that can help you do that. People who are paid incentives in various walks of life set to be put up there for research that you can tap into. We've not used any of those ourselves to date, but that's certainly one way to go. Get those prototypes and questions out there to people who are in the business who are incentivized to take the time to give you some feedback. But incentivized by a third party, not directly by you, so you're not skewing your outcome, if that makes sense.

MJ 07:18 Yeah. Absolutely. And how do those conversations go? I think in our practice, we have a pretty good mix of products that are being built for customers that we currently have. But for the customers that we don't yet have, or if we're expanding into a completely new area, how do you go about getting somebody on board? I mean, this is an investment of time from a client that's probably quite busy with their normal day-to-day operations. So what sort of things would you say in order to get them to be involved in prototypes and assist at that early stage before maybe they see a lot of value from the product?

CD 07:52 So I think, quite often, you won't be necessarily sparking ideas completely out of the blue. It's more likely that in a conversation with someone else, you've picked up on a particular pain point in a particular regime. So maybe it's in the compliance regime or in a healthcare informatics regime. So hopefully you are starting from, I guess, a little point of light to suggest there's a challenge there. I think from there, it is very much—you've got to really avoid going in with a preconceived idea of that product, and you definitely have to avoid coming across as though your whole intent is to actually sell something. It sounds perverse, because of course that's your intent at the end of the day. But you really need to be in listening mode, and that's the key. And it's still a challenge to get that time commitment from people, but working those relationships, potentially, as I say, using some of those third parties that do exist who are doing the incentivization, getting the message out there.

You see quite a lot of this now, general surveys that are just up there on company websites just trying to tap into that, "What's your next big pain point?" Keeping it almost generic but not too generic to actually go out there and do a little—for want of a better phrase, and I hate to say this—but to do a bit of fishing, I suppose, to latch onto where those pain points are. And it might just be something that's already been solved but could be being solved quicker, faster, and that's where it goes full circle back to that innovation versus value. It may well be that the customer doesn't know the problem they've got can be solved in a better way. So it's working your contacts. It's possibly using those third parties. It's listening, all the time, and, to be fair, it's one of the biggest things we can do. Not trying to sell when we have these engagements, but listen to what the pain points are. What is the job to be done? And what is the customer trying to achieve? And what outcome are they looking for?

MJ 09:57 Absolutely. So it sounds like making sure that you're constantly in touch with the clients, early on, is a good way to get them to buy into the idea, but also to help you shape that and poke on a couple of different ideas, maybe see if it could evolve in different kinds of directions before you ultimately choose how that product will look or be built. When you're going through that process, how do you maintain focus on the customer rather than building a piece of technology? I think it's very easy for our team to want to build very cool things that look fun and that we like, but it's important to keep that focus on the client, because very often we're in a completely different kind of buyer. We see the world from a different perspective, and that actually is not what the product needs to be. It needs to be what we're asking the client about. So how do we maintain that focus when we're going through that very early phase and trying to come up with cool ideas that we think could be interesting but maybe aren't hitting the mark for the client?

CD 10:58 Yeah. I mean, we touched, before, I probably mentioned user personas. And again, they can be a challenge in their own right, really, that it's very easy to sit behind a desk and write a user persona of a typical user. And if you're not careful, you'll write the user that you want, not necessarily the user that actually exists. So getting down into those, I guess, jobs to be done with these individuals, and getting them to walk you through what that current process is, really. We can bring the technology to expertise, let's say, in any given area. You can bring the technological expertise. You can highlight those things that can be done better, faster, and in an automated way, possibly fully automated way. But until you can get under the skin with someone who really understands that kind of domain expertise, and that's got to be an existing individual in that area or walk through the process.

You've got to be really, really careful that you're not shooting your head into, "This is the process. This is the outcome." It's got to be marked through that process with that domain expertise. And I think we've said for a long time as a practice that we can bring technological expertise, we can bring institutional knowledge, but the domain expertise, not all the time, but often, certainly needs to be brought as much if not more by the intended customer than it does by us. And actually, that consistent iteration, and it's like if ideas that would unfold even before you get to iterating wireframes and prototypes backwards and forwards, or dare I say, even alpha and beta tested.

MJ 12:47 Yeah. So one other thing I had been thinking about is even if we're in front of these clients on a regular basis, one of the challenges of a business-focused software product is that sometimes, unlike a consumer good, sometimes the person who's purchasing that product is not the same as the person who's ultimately the end-user of that product. How have we dealt with that challenge in our team and what are ways that we can ensure that both or all of the stakeholders involved are actually buying into the product?

CD 13:19 Yeah. You're absolutely right there, Michael. And that's a really important point that just getting potential customers to speak to is one thing, but customers come in in various guises. The person who signs the dotted line to buy it is potentially buying it to look for business outcomes or specific business goals, which obviously is facilitated by having whatever that solution is. But ultimately, that solution is used by a whole bunch of other people who have actually got to get the job done. So that is very much about us getting—and we strive to do this—that mix of individuals. Everyone's looking for a different outcome or indeed a different output from that solution, and ensuring that we get to the real users of the product is key to this, because whilst for example, your reporting might be critical to someone who actually needs to go to board and justify, be it volumes or financial values in any given particular month or quarter, behind all of that is the poor soul whose job it may be to actually input all of those invoices or potentially transpose all of that information.

So very much getting user kind of groups very away? for us to get across this. Ensuring that we get those different hierarchies of individuals and different tiers of individuals who have different wants and needs from the product. One product won't just fit one need. Making sure we drive as multiple needs by talking to multiple people among that journey, that product's journey is the way we have to achieve that. And again, back to what I was saying before, that will come out of mapping the process. This isn't just about "Mary has to do this job"; it's about what happens with that information when Mary's done her part. That information then gets aggregated up and goes to a report that Jill or John has to then pull together to take to board, and then board may dip into that and look at it at a different level because they want to reach a more global view of life. So very much taking that full spectrum of people who interact with the product, and I think that's a good way of phrasing it rather than just users. I think saying users can get you very bogged down into a particular mindset.

MJ 15:43 So it sounds like if we're doing everything correctly, all of the different incentives should be aligned among the stakeholders. So if a user has a certain job to be executed upon, and this product serves that specific job very well with a good user experience, that would make the end user's life much easier, which in theory would, in some way, support the stakeholder support of, or the stakeholder objective of, making sure that we're as efficient as possible, maybe it saves that person a bunch of time, etc. And so I guess as long as you're making sure that those incentives are aligned, that should streamline to make sure that this process flows properly. And along those lines, since we're spending so much time focusing on different kinds of users and the user journeys, different kinds of stakeholders, it sounds like there's an exercise around classifying who is and who is not a customer.

And along with that, I know we have a handful of different acronyms that are thrown around all the time, from PAM to TAM to SAM to SOM. I'm just wondering if you could just spend a couple minutes going through and talking about those, how they're used, and how it can be something that stays on the front of people's mind as we're understanding the relationship between different kinds of users and stakeholders in the product process.

CD 17:00 Absolutely. And you're spot on there. I'm sure Octavia touched on this when she went through the process around that jobs to be done and problem scenarios, as well in drawing out—just back to your first point though, in drawing out those users, and getting to those jobs to be done through a situation motivation, an outcome-type approach, which is getting people to say, "When such a thing happens, I want to, so I can." And get into that real need and job to be done, and then asking them what the alternative is as well. So sorry to loop back to that, but just looping back to your original point there about how do we get down to those perspectives.

But yeah, just back to what you said about some of the acronyms, so you touched on the PAM, SAM, TAM, and SOM there, which is quite a mouthful really, but very much with that, we're into the market analysis in terms of trying to scope out—so this is something we would do in our define stage, and trying to scope out exactly what that potential market is for our products. So to run through that without getting you into too much detail, quite often, the PAM aspect of it, which is your potential addressable market, quite often doesn't appear, to be honest with you, but here, you're basically looking at the—keyword there is potentially, really. You're looking at the potential addressable market for your product. So here, you're not even getting into where you're initially going to focus.

A good example here might be that you ultimately plan to expand globally, but your initial target market maybe is going to be the US. So potentially addressable market quite often isn't where people start. But it's certainly one that you can bear in mind in terms of trying to scale where you're going.

And your TAM is your total addressable market. So that's essentially your question: "What is the size of your market?" And so if you're targeting the US, for example, then that's your total addressable market. Now whether you get down into numbers of potential customers in there, whether you start to express it as potential value at this stage. We're at the defined stage here for us, so we're not writing a full business guess at this point, but we'll do that before we check everything off to give a real go-live. But we need to know what's accessible out there, what's addressable out there, what have we got to go on? I mean, another way to think about that could be the total amount of demand that exists in the market for whatever it is we're building—

MJ 19:30 What would be the practical difference between the potential and the total addressable market? What would be some examples of areas where they may differ?

CD 19:43 So your total addressable market might be, if you're absolutely going to release a new product or look at designing a new product, and let's say it might be the US in the totality, which is where you're going to target, and you might find later down the line, as we get into the SAM and the SOM, it might only be the east or the west coast. Well, let's say your total addressable market is the US. If you've got a product or a service that scales beyond the US, or possibly scales into other industries, then your potential addressable market could be global, if you're moving from the US if it's something in a particular sector. Or it could be into another sector, could be a potential addressable market. If you've got more of a service-type product that can scale, or something that's industry agnostic, you may well start with manufacturing and then move on to another industry.

So very much your total addressable is, "What am I going to target to start with in its totality?" Your potential is, "Where else could we go or where else could this go?" And that might only come out further down the line, potentially, as your product evolves and as you realize that there's other markets there.

MJ 20:54 Great. Thank you. That was very helpful. And then we move into, I guess, after the total addressable market, what are the SAM and the SOM?

CD 21:03 So the SAM are the serviceable addressable market. So if I stick with our US example, the SAM is, best case, the market you can realistically reach with your current resources or your planned resources. So you want to target the entire US, but let's say you're actually only a smaller company, you've maybe only got sales channels in a particular part of that country, so that's my east coast/west coast example perhaps. It may well be that your serviceable market is only one of the coasts because of your current sales channels. So we might have took our total addressable of the US and immediately got it down to, who knows, 25 percent, 50 percent. Because at this point in time, we're actually only able to service a fraction of that market, so that would be a serviceable addressable market.

From there, you get into your final one, which is—well, certainly for us, where we're managing it—your serviceable obtainable market. So that's addressable, that's what we can go at, but what can we actually achieve in there? Because what we've not done yet is actually scaled this to what we actually expect to obtain. So what you target and what you actually achieve obviously are different things. So in the serviceable obtainable market, we're actually starting to factor in things like the competition, that we haven't done so far, scalability, the actual customers, the size of the groups that might be out there. Some of our feedback.

And then the product adoption, which is a key thing, there's a whole other challenge around the product adoption curve. So it might be that, let's say, we got down to 50 percent, because we were looking at the west coast at the US. But that doesn't mean that we're going to achieve that 100 percent, does it? 100 percent of that, because of course that's just what we're aiming for. It might well be that we're only going to appeal to early adopters in that market, which cuts that percentage down to anywhere between 10 [percent] and 15 percent again. Or it may be that customer feedback says there's only an 80 percent interest. Not every customer is going to want what we're producing. So you get right down to your serviceable obtainable market. So we've really run the whole gamut from part of the possible down to practicalities of a country that we're working in, down to at the moment we can only service a portion of that, and of that portion, these are the customers that might want it.

MJ 23:27 That makes so much sense. So appreciate you starting from the widest funnel possible and then moving our way to a more and more narrow-focused group of entities that we want to target. When you mentioned the product adoption curve, I think that was a very interesting and great place to go. It is important for us to all note that companies are just like humans, in the sense that some are willing to take the risk on new kinds of technology or new kinds of products before others are. And I think probably most people have heard about this concept and maybe even seen that curve on things like Gartner and other places. But could you maybe spend a little bit of time on that product adoption curve? And who are the different major players? How do we use that to drive a bit more context, I guess, especially the serviceable obtainable market? And how would you recommend that people think about that when they're charting out the growth of their product over the next three to five years or potentially longer?

CD 24:26 Certainly. I'll probably be trying to create a bit of a picture in your mind as I go through this. So as you quite rightly say, I'm sure a vast amount of people are at the product-adoption curve and certainly not taking any credit here for this. But really, what you've got in the market obviously—and some of this depends on obviously the product you bring into market, so that there is a big overlap here, and we just touched on it in the market analysis side of things there, but in the market, you've got a whole gamut of users. And traditionally, on the product-adoption curve, if you think of it almost a bit like a bell curve really, you've got, I guess, five groups traditionally is what you see of innovators, early adopters, early majority, late majority, and laggards as groups of customers.

So there are five different customer groups, for want of a better phrase, in the product-adoption curve. And if we think about those on a curve moving left to right in groups, you've got innovators, early adopters, the early majority, the late majority, and then laggards, for want of a better phrase. And what you were saying are groups of customers with different needs, different drivers, different desires, within the split in two different portions really of the size of the market they would make up. So typically, this percentage is attached to these groups, and certainly the one that we're working from would see about 2.5 percent of the entire market being innovators, and I'll talk about some of the characteristics of them in a second. About 13.5 percent or thereabouts very specific are now early adopters, which gives you about 15 [percent] to 16 percent of the market being—let's call them revolutionary rather than evolutionary. And then from there, you get pretty much a 34 percent split-ish on early majority, late majority, and then 16 percent of those customers, they were maybe at the end of that journey. And we've turned them with laggards—well, these types of groups obviously display different types of characteristics and are going to engage with you as a provider of a product or not based on what it is they're looking for and what you are offering.

So when we talk about innovators and early adopters, I guess another way to think about those kinds of groups of visionaries are enthusiasts. They're really looking to drive change. They're not afraid to fail. They really do—they're evangelists for technology, certainly like to be the first to try and buy things and engage with things. And from your perspective as a producer of a good or a service, I'm not afraid to have something that's still potentially in development, to get on board early. And to get the benefits of being on board early, they'll happily put up with potential bug fixes, and they've got a high tolerance for risk and uncertainty and ambiguity. So those are the types of organizations who'll be looking to get in early doors, potentially even partner with you to get this product out the door, and will help you drive it, but very much looking for change and very much risk takers.

As you move into your mainstream adopters, which are your early majority type of customers, you're getting into selling your early majority, a pragmatic approach to things really, but they're very deliberate individuals. They will go along with groups, so they're likely to be followers of the early adopters, certainly, and will latch on and perhaps ride on the coattails a little. But they are the group that will help your product gain some appeal, but they do want to wait until it's been successful in practice. So they're going to be starting to look for some of those returns on investments and some of those key benefits.

In with those as the mainstream adopter group, you're looking at your late majority. You're starting to get into those individuals who are perhaps a bit more skeptic now, or skeptical, I should say. Only looking really to adopt after it's been proven elsewhere, more likely to be driven by necessity than choice. Certainly not big on embracing change. Like to know the rules, kind of creatures of habit-type organizations and individuals really. Like to see everybody else doing it first, ultimately.

And then right at the end, you've got essentially—I've termed them laggards, but essentially, they are the resistors. They're change-averse. They're not leading the way. They'll often wait until they are forced to adopt a particular product and just unlikely to buy into new ideas. So there is a question mark there as to whether you ever do get the laggards on board or whether you want them on board. And there's a strong suggestion that by the time they're on board, have all the technology, have all the products come along, that they're already in the innovator or adoptive stage, that are potentially just looking to, again, move through that process.

So five distinct groups. And I'm conscious that's a lot of information to push out there, but they're very much split in that way that you've got almost—I think I might've used this phrase before about the chasm that exists between those—I think I used the term evolutionary and revolutionary. There is a gap to cross. And that brings us to our next challenge really.

MJ 30:08 Yeah. So when we're looking at this distribution, which is divided up by I think standard deviations, it looks like the ideal situation would be to actually set up your marketing and outreach program slightly differently based on the role that that product currently has in your portfolio. If it's something that's brand new and you're still trying to understand, "Is there a product-market fit, can we co-create this with some of these innovators in the marketplace?," you're going to be targeting entirely different kinds of firms that are willing to roll the dice or sit with you and have the patience to build something together that could benefit them later on. And one thing that we've actually tried to do as well is to potentially come up with those partnerships and reward those innovators and early adopters if they are part of the growth of that product down the line. So, I think there could be incentives there to bring them onto your team and ensure that you grow and succeed together, give them a vested interest in ensuring that it works out really well.

And so I know you're addressing and targeting a completely different kind of firm and individual in that first phase, and then as you mentioned, it's crossing that chasm that then gets you into a place where you're actually starting to see profitability and probably do quite well with mass adoption of a product. So, what are the challenges that you would say in crossing that chasm? If you've got on the left side the revolutionary innovators and early adopters, how do you get people from the early majority to start jumping on board? What are some of the ways and attributes that you may tailor your products? Or is it entirely different, and you're just focusing on marketing it in a different way?

CD 31:55 Yeah. I mean, there's quite a few different techniques, and you're absolutely right to point that out as well, Michael, in that early majority it absolutely is, even at the point where you're taking your product to market, it doesn't have to start, you don't have to take it to the innovators and the early adopters first, of course. Your early majority may well have some pretty standardized, let's say, processes in place, and you're bringing a technology that helps them to do something that's known, that's controlled in a much better or a faster way. That's not a big risk, so you potentially can take some of those products to that part of the market quite quickly. But certainly, to your point, if you're bringing something through the ranks, and you're absolutely right to say that those first innovators and early adopters are incentivized in some way, they are really the ones who are going to help you create those benefits, that return on investment that's going to convince your early majority to get on board.

So the difference between your early adopters and your early majority, which is where that chasm is, they are looking for things like no major bugs left in the product, so will be of looking to—you're never going to iron out every bug, of course, things are going to come along, things are going to be identified, but they're going to be wanting a stable product. They're going to want to see things like case studies, they're absolutely going to want to see those organizations that have been there, used this, the benefits that they got, drawing out those benefits into a return on investment. Potentially, you still might be looking at some aspects of a free trial, and that's very different to what you might have offered your early adopters or your innovators, which might have been a completely free product, but definitely something to get them in, to get the product in front of them so they at least get a chance to try it.

You're also going to want to—I've outlined what the USP [unique selling proposition] is. Again, the early majority are looking for something that is better than what they've got, so what does it do for us that our current solution doesn't already do? And as I mentioned, benefits and return on investments are going to be key, because everybody of course is going to have to be making a business case along the lines to investing in a new product or service. But obviously, that was perhaps an easy decision for an early adopter or an innovator who was perhaps getting some financial incentive to take it on board and of course wasn't risk averse to start with. So it's got to be at that point where they can relatively easily make the case to change. They will accept change, those early majority, they absolutely will accept change, but it does need to be laid out for them. They have an aspect of adventures about them, but they're going to be wanting to see what is delivered elsewhere before they take it on.

MJ 34:47 Thank you. That's super helpful. I think it really brings us to a great spot here to take a step back and look at the entire process in the context of whom we're interacting with, whom we're targeting, how we want to both grow the product internally as well as ensure we have the right people on the bus externally in those early adopters and innovators, and how we may want to tailor our approach to interacting with them over the course of the product process as it evolves and grows. How do we think about this in the context of our full product process, and what are some of the ways that you'd tie this up and put a bow on it? I think that this is the most important piece of the product process; it involves how we're building the product, how we're interacting with the early customers and getting feedback from them. So if you were to wrap this up into a single takeaway, what do you think is the most important part here?

CD 35:43 So, as you've said, we've talked about a process there, and it is an iterative process. There might be seven stages, but of course, with the same product you can keep coming back and iterating through stages, and you will. Once a product's in its life cycle, you will add new features, you will iterate, you will deliver updates, you will eventually sunset a product. But I think what process does for us and what it does well for us is it can keep us on the track of building the product right. The whole goal here of course is also to build the right product, and I think that's it in a nutshell. We need to build the product right, but we need to build the right product.

MJ 36:21 Perfect. Thank you Chris. I think that is an excellent way to summarize it. Building the right product is certainly the focus of the product process at the beginning. And I think, hopefully, I'll have some of our other team members on to discuss what it's like to build the product right in the future, because I know there are a lot of nuances around that. And managing an engineering team, it's a completely different animal than what we were walking through today. So thank you so much, Chris, I really appreciate it.

CD 36:47 It's been great to speak to you, thanks very much.

MJ 36:49 Perfect. It's been great to speak to you as well, Chris. Thank you so much for everything, and I will talk to you soon. The views and opinions expressed in this podcast are those of the participants and do not necessarily reflect the opinions, position, or policy of Berkeley Research Group or its other employees and affiliates.