LaunchPod: Sharon Hunt
===

[00:00:00] 

Jeff: All right. Sharon, , welcome to the show. Thanks for coming on

Sharon: Hey, Jeff, how's it going?

Jeff: I am good. I'm excited about this one ' cause I think there's some really interesting, like, real, experiences you guys are having over at JLL with how you're kind of adopting AI and how, you have ended up moving faster now.

But, like, the real process took a real company to get through. It's not all just, you know, have, , Claude walk up, sprinkle a little AI sauce on there, and have it magically work. So I appreciate, you know, you kind of telling the story of what was the real process of a, you know, company that's been around as long as JLL has to get to AI first, AI speed kind of stuff.

But, , maybe before we jump into all that, can you just give the TLDR for anyone who doesn't know, maybe like what is JLL and also , how did you get to where you are? What's your background that brought you here to product leadership?

Sharon: Sure, yeah. I'll start with, , JLL. JLL is an acronym for Jones Lang LaSalle. It's one of the oldest commercial real estate operations companies on the planet, and I think it's now 191 or 190 on the, , top [00:01:00] biggest companies in the world on the S&P 500. It's a pretty big global company, and they do everything from leasing to facilities management to, , buying and selling buildings on behalf of clients to property management, which is the operational arm of the business that my technology organization, , enables.

, Within the property management technology org, there's also an acquired company called Building Engines that, builds software, software as a business, and that software is both used internally at JLL, , as a global platform for property management. It's in all buildings where JLL, , runs the property, and we also sell it out to the direct market, to other property management firms or big institutional investors as well.

So that's kind of the, the landscape. , And I got there in sort of a circuitous path. ... My background has been everything from B2C to B2S and B, and now B2enterprise or enterprise squared, I think almost in this environment. [00:02:00] But I started a startup called DocStock based in, , Santa Monica, California, that was eventually acquired by Intuit.

And then I ran, , execution for the self-serve, , TurboTax product for a number of years and built some of the very first AI-powered personalization features there with a fantastic team. , From there went to, , another San Diego unicorn called Housecall Pro, which is a field service management solution.

It's been doing exceptionally well. , From there I, I built a little startup called Clovers.ai that was an interviewing, , HR tech company, , and that was - right before I moved over to, to JLL. So I've really run the gamut from very small early stage to extreme legacy and then B2C all the way to B2enterprise across a multitude of different verticals, tax, home service management, , real estate operations and HR.

Jeff: Nice.

When we talked previously, , one of the main things that made me really want to, to get you on, and I'm really happy to have you, that we can talk about is we all hear across the world everyone talking about like, [00:03:00] oh, building's, you know, free and instant and there's no cost to build anymore, which, , with AI might be true if you...

You know, starting from zero, sure. , You can just build whatever pretty quickly, , and you can at least make a kinda half-assed, , decent version of almost anything. , But like you said, JLL has been around for 100, what was it? 170 years, something?

Sharon: for 200, some

Jeff: yeah.

Sharon: mm-hmm.

Jeff: So I mean, there are applications you're operating with and you've acquired a bunch of companies that have been around for longer than a lot of the, , AI founders and, and researchers right now have been alive.

, Sure, AI works great for React and all the modern, you know, kind of structures and, and simple applications right away, but like, there's more complexity when you run into something like that. Like, you can't just take Claude into one of these applications and say, "Go," right? Like, there was, there was a process there that you had to undertake to get to being able to use that stuff at scale.

What did that look like? Or, or is that true or were you just able to go like, you know, "Just YOLO it, let's go"?

Sharon: Yeah, I mean, there's a number of ways that we're definitely using [00:04:00] AI to, deliver things much faster, and there is certainly a lot of limitations and ceilings that we're hitting too, that were maybe obvious in hindsight, but kind of going into it, , , not necessarily as clear. So I'll give a couple of examples.

... Under the Building Engines business, there's a flagship product called Prism. Prism is a complete solution for running a property management organization out of a commercial building. So think about all the activity that occurs in a building between property management staff, the engineers, the tenants in the building, the vendors that perform work at the building, and there's a lot of coordination that has to happen.

Work orders are sent, visitors are, , invited and have to go through the access control systems. Inspection rounds need to occur. There's a lot of activity, and so the platform really facilitates all of that activity, , which does also generate just a, a really big corpus of data that ultimately can be leveraged for AI.

The product Building Engines, , the company's been around since 2001, but the [00:05:00] flagship product was rewritten starting in 2018, so it's now already about eight years old. So even though it's a newer version of , the company's flagship product, it's still, for software, relatively aging at this point. So definitely a brownfield application.

So what we learned trying to deploy, , and speed up development on this application using Claude early on, was that Claude was running into a lot of the same challenges that our, new engineers were running into. , The code wasn't always well commented on, , wasn't necessarily structured in an optimal way.

Sometimes there were, , functions that were embedded within functions that were embedded within functions, and you had to do some Sherlock investigation to understand what something's actually doing and the downstream systems that it would touch. And then our front end was, largely hand-rolled.

So we weren't using, , a dedicated design system. So even trying to do something like spinning up a prototype, Claude or Cursor at that time actually was, hallucinating a lot and just building UI , with no input or no context for what [00:06:00] the product should really look like. , And it was ultimately, you know, we would be putting...

You wouldn't put these concepts in front of customers because it would look like a different application ultimately. So we really just weren't getting the juice out of it. So we said, "Look, we need to go back to the drawing board a little bit, and we need to clean up our product so that it is AI ready."

And so we've been on that journey now for about a year. We started with a small team, a test team, and we rebuilt the tenant portal, , - that's one, in one phase that's just tenant-facing. , One of the lesser used, right? 'Cause our power users are property teams, so tenants are only interacting with the product every so often when they have to report an issue.

So lower risk, lower surface area, and we just put a very small team on this, and they were able to rewrite the entire portal in about a quarter. And we estimated that would've taken about a year in the old, process. And in so doing, they built a series of skills, a series of frameworks. They, , leveraged an LLM-optimized design system at JLL called Solstice.

And we said, "Hey, there's really [00:07:00] something here. This is a dramatically better experience." We were able to really modernize the look and feel, make it feel premium, take on a bunch of, , additional feature requests. So starting in April, we've been rewriting the entire web app for property managers doing the same thing.

So it took a team of three, four people and then enabled another larger 70-person, , R&D team on similar processes. Now we are about 80% through that journey. And so what we're seeing is that the app is dramatically better. In fact, just yesterday we started to bring our very first users into the new experience from property managers and getting some early really good feedback.

We were able to execute some 100-plus requests during this rewrite that were sitting in our backlog. , We're four times faster now just in terms of throughput. But what we're seeing is that now it's the functions around us that have ceilings. So there's only so much change that your sales team can absorb.

There's only so much your CS team and your implementation team can absorb. They're real humans that [00:08:00] have to learn the product constantly so that they can guide customers through it, answer questions appropriately, be able to sell it, truthfully in, the way that reflects what the product does today- And then users also have not a super high tolerance for change as well, especially when it's, , an application that's embedded in how you get your work done.

So it, you know, it's gotta be really intuitive, these changes, but if you really dramatically make big swing changes constantly, you're gonna fatigue your users. And when your users have their own customers, so tenants in this case, in the value chain, are the customers of our customers, you really can't mess with that.

You gotta make sure that your customer's customers are really happy and aren't, you know, feeling like they're, , constantly having to re- relearn or, absorb change, because that's gonna come back to the property teams, which is gonna come back to us as negative feedback. It's all of the scaffolding and the enablement around the product that just, it's human, , absorption that's the new, , [00:09:00] limiting factor

Jeff: Yeah. No, I, I, find it really interesting, , how you all went about this because, , like you said, you can't just take, , Cursor in that time and, point it at, a huge set of code that, maybe it's one thing if it's had one run through fairly modern, you know, frameworks and, you know, well commented, all this stuff.

But it does work really well to build net new because it built it, and so it, it built the memory and it built all its own kind of... Even if it doesn't comment , the actual code, it has its own memory systems and context around what it built. If you're taking it into a small app, it can generally learn that.

Like, I've, I've done that with a couple internal applications we have here, where you can just point it at it. I got access to the repo, and it was able to figure it out, and changes were pretty easy. But, you do have context windows and, and large amounts of, , data and, like you said, then abstractions built into abstractions built into abstractions and, and stuff that you have to follow through to really understand what happened.

, We've both been around long enough that we remember the stories of companies that had, like, the server in the closet that you weren't allowed to touch. No one knew what it did, but the one time it went down, the whole [00:10:00] application stopped. So, like, just no one touches it anymore.

Sharon: It's locked. The room is locked.

Jeff: exactly. And you 

Sharon: the IT guy has the key.

Jeff: yeah, and e- even he's only allowed to go on it, like, the third Tuesday of every month or something silly. , But, like, one thing I do,, applaud , the leadership team over there for, 'cause I feel like I hear the opposite of this a lot, is I hear people kind of complaining, " ...

You know, we got Cursor," and then , the leadership team of the company was immediately like, "Why aren't we going faster? Why can't we rewrite the whole thing? Why can't we just point it at it and go?" , But the kind of, you know, ability to look at it and, and say, "We have work to do to get there," but it sounds like it still made it a lot faster to be able to go in and use these tools to kind of rewrite into a place where you could now just go, you know, pedal to the metal.

It shows you kind of gotta go slow to go fast, but you were still able to go faster than maybe usual. -

Sharon: Yeah, I think that's a really good way to put it because we, you know, for all intents and purposes, we've kind of stopped shipping major features out to the market for the last, call it six months, and that's a painful choice to [00:11:00] make. , The majority of what we were building, we were building in the rewritten product, which basically we had to get to a certain level of readiness, which we just got to as of this week, to even start to point people into it.

So you gotta be brave and, you know, have enough faith that you're gonna be able to get there fast enough, and six months is a l- a long time. , In a B2C application, I'd venture to say that would be untenable. In a B2E application, we have a little bit more leeway because , the change management is really painful.

, The sales cycles are longer. , So although we still need to work with urgency, a six-month, timeline , from the current app to enough of the app rewritten that we could start to enable clients on the premier most used parts of the product, , that wasn't gonna threaten us too much.

And that now we're in positions going into 2027 where we will be able to focus on, , innovative features and capabilities that we just weren't able to do before [00:12:00] because we were spending so much time struggling, right, in the code base and spending so much time just trying to spin up a page of... I mean, it's, drop-downs and - , and input fields.

We shouldn't be spending time, you know, building these things over and over. That's the kind of thing that AI should really be able to help us with, and we realized that we just weren't in position to be able to do that. , So we had to build the frameworks. I think it's all depends on the context. It depends on your particular business and where you're sitting.

for us, it made a lot of sense because our, UI needed, it needed to be modernized. We needed to get to a point where we were able to run with speed because we were slower than we should've been. , So now we're, we're s- we're gonna be so fast we , we gotta figure out the other problems, but I would, argue that's a much better position to be in than still being kinda lagging behind and, and not being able to execute with speed. 

Jeff: Before we kinda get to the, the speed limit now that you're kind of at that point where you're able to move quickly, you've moved-- You know, you've started to move people onto the, the whole app.

You have moved people onto kinda the smaller , , [00:13:00] first app you kind of ported over and, and got your learnings from. Looking at how you work with customers to figure out, what do they want? What do they need? What are the next things that need to be prioritized on the roadmap?

How does that work now? Did this rebuild allow you to be, you know, acutely faster at kind of that level now, or are you still in that process?

Sharon: I would say we're, we're still in it, but we've kind of been running things a bit in parallel. So at the same time that we started to unleash the broader R&D organization on this rewrite, we, , moved to a different prioritization model Prior to this year, for a number of reasons, we had a lot of, call it random pressure on the roadmap.

So, , regional needs from, from JLL as we rolled out into new, , countries, or clients from older building engines applications migrating to Prism , that needed feature gap closures in order to, to feel confident signing the contract. And so all these things sort of created, , acute time pressure at what [00:14:00] seemed like a almost random list of feature requests.

It didn't really ladder up to an overarching strategy. So we've been able to alleviate that pressure, which was step one. , And then as we got into this mode of, , really focusing on the user experience, , the look and feel of the application and putting ourselves into a position to run really quickly at the same time, we, rallied the entire team around a series of customer benefit metrics.

I come from a school of thought where if you can clearly articulate why you exist from the perspective of your customers, , what are they hiring you for? What's the quantifiable, , measurable benefit , they're getting from you when they buy your product? Then you can rally the team around those things.

And for us, it's ultimately it's saving time for the property staff. The minutes, seconds, hours, days that we can shave off of repetitive workflows or things that they're doing, that's the more time that they can spend on strategic activities, building great relationships with their tenants, which is a key to retention.

, We think about [00:15:00] maximizing NOI, which is net operating income. So how can the product on the margins find opportunities to increase revenue or decrease operating expense, , through the activities facilitated in the product? And the third is really about deployment speeds. We wanna make it really easy for a net new account or a new building to go live with a product.

So that lens really helps guide the roadmap. Now you've got a framework. Now you can look at a feature request or an idea and say, "Okay, does it move the needle on one of these things? Let's get the numbers to prove it. What's the volume of that workflow?

How much time do we think it's gonna save if we do this? What's the baseline versus now?" So that's kind of the framing, and I think this, rewrite has helped enable that thinking.

I'm seeing for the first time a lot of really great ideas coming back from the R&D teams, specifically developers, because now they understand these metrics and they can say, "Hey, I saw this opportunity. Here's an idea for how I can solve this particular problem that ladders up to one of these key KPIs."

, And they are able to spin it up in a [00:16:00] prototype and design it really quickly, and we're seeing more energy around it because , there's something to be said for even if a feature doesn't dramatically move the needle, but it's still strategically aligned, if it's a relatively low effort and it creates motivation and buy-in from your R&D teams, there's a lot of value in that.

Because then you get energy, and energy is key to culture

Jeff: Yeah, I mean, velocity and speed are not the same thing.

Velocity is, is a vector which has both speed and direction. And you can be really, really fast and just go really fast in the wrong direction and just put out a bunch of trash. Or maybe it's really well-written features that just your customers don't need, right?

But you've kind of looked at this, and , the things that were getting in the way and almost obfuscating the ability to, to really focus heavily on - both of those kind of pieces of, of the vector are-- There was just a lot of stuff on the roadmap that had to be done. It was [00:17:00] high priority because it had to do it for, you know, regulations and, and all those kind of things that are really, really important.

But maybe the team didn't find the most exciting pieces because, it wasn't hitting on, like you said, the core benefits of what you bring to your customers, aside from they could use it as long as you did it. If It was table stakes. I find the table stakes work , of that less fun than working on the, the how do we get further benefit to the people we're building for.

Sharon: In my travels, that's kind of universally true. You know, I think if you come to a team and you say, "Let's build this feature and it just has to be done by April 1st,"

that's a very different story than, "Let's go solve this problem. This problem is important because of X, Y, and Z. And I would love to understand or - I would love to hear from you what are some ideas that you have to go solve this problem?

, And by the way, let's put you in the building with our customers, and you can - see this problem in real life, and that's gonna give you even better ideas at the end of the day."

Jeff: Yeah. So that, that kind of brings us to [00:18:00] naturally, I feel like, the next piece, and we, we kind of glossed over this or alluded to it, you know, here and there already. But if you're building quickly and you're able to kind of focus on these problems and, like in, JLL's case, you have updated, , the code behind some of the older applications so you can go screechingly fast, in, in code and building.

You still have the problem, though, of people have to use this stuff to get value. I mean, if you were to go dump, 100 new features in one day, I almost don't care how good they are or how useful they are. Like, people are not going to find them all. How are you solving that? 'Cause I feel like that's actually the next big problem we're facing.

Sharon: Well, one of the things that we're looking at really is, , is more, , embedded workflows. So we study a workflow end to end, then a lot of the things that we're building are just part of those workflows. So what I mean by that is we've got a bunch of flows in the product that start by creating a record, a certificate of insurance. You sit there and type in all of the insurance profile information and the coverages [00:19:00] amount , and go find the AM Best rating, and it, it's, it can be quite tedious. And if you're doing that, you know, a dozen times a month or more oftentimes for some of these buildings, , it's super time-consuming.

Same for things like a lease or, an invoice or a, a vendor contract. So we think about, okay, well, let's make that easier, but don't make the customer have to go discover something new. Just take the workflow that they're already used to and now embed this into it. So when you drop a file, now to start,, when you create a COI, a certificate of insurance, just offer the option to drop in a file, right?

Versus starting to have to type in things from scratch. This goes back to iteration versus net new builds. So we're not necessarily trying to expand the platform into doing more and more activities. Now we're trying to make the activities that we already support as seamless as possible.

So it's about iterating on the workflows that are tried and true and , well-trodden in the product, which eliminates a lot of the need , , , , for our users to have to discover something net new.

Jeff: I [00:20:00] think a lot of people look at build fast and think, "Well, let's add," you know, , in JLL's case, I'm, I'm probably gonna horribly butcher what would be here. , But let's add, you know, the ability to, , you know, interface to buy property or to list on the, whatever the commercial version of the, , listing system is, or, , a million other kind of net new things you could add that are, are tangentially related, but, and maybe it's a different person at the org, or maybe they just have a tool they already use that does it really well, and , there's no pressing need to move into other areas.

Sometimes there's gonna be, right? But, like, but looking at how can you add value 'cause you don't wanna add complexity or stress to the person unnecessarily, to the customer. So, how can you do that and still move quickly and, build new and take advantage of your speed is, like you said, let's focus on making the tough parts easier.

What is, friction that wasn't worth fixing before that we can now? , how's that process look? Is that, is that, like you said, kinda sending people out , to embed with customers? How do you kind of find those things that are gonna be the highest leverage?

Sharon: Yeah, I [00:21:00] think it's, it's three things. And this is not, new in the world of AI. I think you've got a combination of, , your quant, so making sure you've got , your logging. If you've got a point of view on what's preventable friction in the product, where are there errors that are getting thrown?

Where are there, you know, rage clicks or dead clicks, or where are there workflows where the, the funnel has a high drop-off? All that standard kind of quant instrumentation through, , a logging tool or a standard, , instrumentation tool so those things are really, really important, obviously.

And then , the other piece is , the qualitative. Following people, being on site, seeing, you know, Gino the engineer in the boiler room trying to complete his inspection while he's sweating and, trying to, press the tiny buttons on your application. You really get a feel for it.

So it's gotta be a combination of the two, and I do think now because our engineers have the ability to come up for air a bit, right? , They're able to, to peruse the [00:22:00] product. So I see a lot of engineers finding things, saying, "Hey, this doesn't feel right. , This pattern doesn't jive with this other pattern.

What's the right approach? , I went ahead and just made this, , UX change 'cause I think it feels nice. What do you think? Do you guys like it? Should we roll with it?" That kind of thing is happening, so that's just critical thinking happening on the part of our R&D , teams too, since they're not just nose to the grindstone trying to get a random feature out by a deadline.

They've got room to breathe. They can come up for air, they can peruse, and they have their own well-informed points of view too as technologists. So I think it's all three of those things, really , great quant, constantly being, , side by side with our customers. , We're creating more and more of those opportunities, and then just being in the product yourself and having your own point of view.

Jeff: Yeah. It reminds me of we had, one of the senior people from a company called Hunger Rush on the show a long time, like a year plus ago at this point, I think. ,

they build software to help run franchise restaurants. , And so it's like pizza restaurants and stuff where there's a lot going [00:23:00] on and you are serving food and trying to use the software and trying to ring someone up and cash them out and do, you know, three or four things at once.

And they described that their product team would go out and actually work a double at some of the restaurants during like rush hours and, and during, you know, dinner rushes. And that was one of the most helpful things they ran into, was they would find that, like, what they thought was a great workflow was fantastic until you realized you had to do it one-handed while talking to someone out the drive-through window, correcting an order on another system, and trying to hand someone change.

And they're like, "You can't actually hit these two buttons with one hand. If we made it closer though, you could do that." And they found that all these like little knits that weren't, they weren't gonna be a million dollar, you know, $10 million new features, but they made huge, huge differences in quality of life for the users, which trickled up to people being way happier and way stickier with the software.

Sharon: yeah. I mean, the property managers are talking to a vendor at the same time they're trying to respond to a tenant email and, you know, you, you really learn so much. There's just no substitute for that. I don't think [00:24:00] that's ever gonna change. , AI is not gonna automate that away.

, That's why I, I believe that humans are still gonna be s- so critical. As long as we're building software for humans, we need humans to understand what the humans need at the end of the day.

Jeff: these things are not new with AI. It's the same stuff over and over again. It's make something that makes your customer better off and find a way to deliver it in a way that's easy for them to use and, and doesn't cause more stress to use it than it causes not to use it.

Sharon: Yeah. What I think is different with AI at least in our world, what I'm seeing, what I'm observing, is that there's more breathing room to do that good work. , And there's more, , ability so when we send teams on site, they can observe a problem and then within an, an hour or two have a real functioning prototype, maybe less, that they can put back in front of that person who they just saw experience that problem and get that level of feedback that you just don't get.

I mean, in, in, in my, my past, you go [00:25:00] out for a ethnographic study, you take lots of notes, you'd come back, you compile all that, and then you spend a bunch of time brainstorming different solutions. You'd ... Then you go back, and it would be a weeks to, if not months-long process to get to a point of, "Here.

Here's something that's really worth building," and now that happens on the same day. That's, that's unique and different. I think that's pretty powerful. , , I am really hopeful that it is gonna unlock that human connection and that human empathy if you use it correctly, if you use it to give yourself breathing room, and also, , allow it to, , facilitate, help you facilitate much richer feedback loops at the end of the day, too.

Jeff: So that said, there must be some kind of new that still happens, you know, net new feature set, , and if you're building those, you know, faster and faster, how do you think about, actual, distribution and, and driving adoption and stuff like that there?

Like, has that changed how you look at releasing new stuff, , because of speed? , Or are you finding that still, you know, it's more just like just [00:26:00] working on the few really important things? How have you balanced that?

Sharon: Yeah, I would say we're definitely mid-flight on that. I think, , current perspective is that, , the small, I would say small tweaks we wanna continuously ship, right? It's like, it's those little nits. You should be able to select all on this dropdown, right? We're not gonna hold those things back.

Those are constantly gonna go out into the product because I don't believe that they need like net new heavy training, right? But when you're, like, fundamentally rethinking a workflow That's something we're gonna hold back a bit more.

So right now, for example, we've rewritten our inspections module. , The rewrite today houses, , a similar workflow to what currently exists in the product. It's got some lightweight UX uplift, , and some of the smaller usability, , concerns we had in the past we've corrected. But we're fundamentally rethinking that entire workflow.

So thinking about, for example, an inspection should be completed with a video or a series of pictures. Don't even force the engineer to have to sit there [00:27:00] and, answer a bunch of questions in a questionnaire. Let them upload , their context from their environment in whatever they want. Dictate through a phone, snap a picture, , create a video.

That fundamentally changes the whole model of how an inspection gets completed. And so we would rethink that workflow end to end, as well as all the places it touches downstream, the reports that it generates, , the way that it feels on mobile as well as web, all those things. And we'd hold that back intentionally for a bigger bang release.

, We wouldn't build something like,, complete an inspection question with a picture until we, shipped all of those things together, because I think it changes the modality of how the entire thing works. , Even though we could, right? Because pieces of that will be ready and shippable, I think we'd hold it back, again, because

We'll be making so many changes, you wanna be choiceful with what you ask your customers to absorb. So it's better to absorb kind of a big flow change all at once than trying to [00:28:00] piecemeal , different, , releases on that same flow over, say, a, a six-week period. That's loosely how I'm, I'm thinking about it high level.

, I think, , the other piece around this too is the enablement story. Once that's released, then you can, then you can enable your solutions consultants , to sell that workflow. You know, it's a lot more compelling as a complete feature set than maybe just the one piece. So then it becomes a more compelling, , sales story, and you wouldn't wanna continuously enable someone on this piece versus this piece.

You just enable them on the whole flow end to end once it's done, and that's true for CS and implementation and all that as well.

Jeff: as a marketer, I always, you know, think about, , not just, of course, customer benefit is the main thing. We have-- You know, the goal is make the customer's life better. , But there's also how do you get someone to be excited about a change? Or , how do you get someone to realize impact or, or see like what a change was actually made,

and, , I think you kind of nailed it there, where you could release a 5% improvement, 5% improvement, 5% improvement, and in some cases, that's the [00:29:00] right thing to do. If it's just changing a little, you know, you can drag in a file versus having to go physically upload it or, or do something, that's great.

But what is part of a really, really big but cohesive, , change, there is, I think, a benefit at times , to waiting until the much bigger picture is ready to go, and then you can train them on it. I, I think that is important and all that, but also people realize , the magnitude of difference much better when it hits at once versus kind of over two months rolling it out.

Sharon: in the old world, you would carve off , your MVP because your resourcing was a constraint. So if you had an idea that you wanted to rethink an entire workflow, you'd - take a step back and say, "Okay, well, what's the piece of that that we can go ship to make sure that the rest is worth investing in?"

And then you'd go ship that, and then you'd measure, and then you decide whether or not to continue to move forward. When you're able to build so much quicker, , that piece of it is no longer as much of a concern. So , if it's [00:30:00] between now and next sprint or maybe even two sprints from now, especially in the enterprise world where you can get a much bigger swing out to market, that ultimately is much better for your customers for all the reasons that we stated around absorption.

, And you don't necessarily, you don't have that constraint anymore. You don't have to necessarily be concerned that, "Hey, I don't know if the rest of this is worth investing in," 'cause that, additional investment is, incrementally more, not significantly more. , And so why not go to market with the bigger swing?

Jeff: , Well, , speaking of big swings and making progress and having time , to empathize with your customers, hopefully you guys have made up enough time with AI , that you were able to give up this time to talk to us. But, you know, at some point we do have to let you go and, and get back to it.

With that, , Sharon Hunt from JLL,

appreciate you being here and, and have a great rest of your day.

Sharon: Thanks, Jeff. It was a ton of fun. I appreciate you having me on