Shipping Product Strategy

Share with

Transcript

I think we're gonna get started, so, it's great to be here.

My name is Wade Wegner. A quick introduction, been building developer tools and platforms for a long time now. Started off in the Microsoft ecosystem, did about ten years of development, realized I wasn't very good at it, so I got into building products. Joined Microsoft just about the time things started getting exciting.

So I was in the early wave of Microsoft Azure when it was terrible. It's gotten a lot better since then. I also ended up building something called PowerApps at Microsoft. Don't know if anyone's heard of PowerApps.

Our whole idea was, shouldn't it be as easy to build a mobile app as it is to build a PowerPoint presentation? So you can kind of think of Power Apps as kind of like PowerPoint and Excel had a baby in its in its Power Apps. And so, did that for a couple years, and that's when I heard about Salesforce. And so I really learned about Salesforce because we were starting to build low code tools for developer.

I ended up coming to to Salesforce when two things happened. In fact, had it not been for these two things, I probably wouldn't have been able to get a job. Now, Karen inadvertently stole one of my punch lines today because in, you know, back in two thousand fifteen, Salesforce was listed as the number one most dreaded platform, by developers on Stack Overflow.

And Salesforce loves to be number one, but this is not one of those lists.

The second thing that happened and I had a build here so that it was a a bit of a teaser here, but a very, very awesome partner of ours actually ended up bringing down multiple times the Salesforce sign up pod. Does everyone know what the sign up pod is? Like when you create a developer account? Yeah. Guess who is responsible for that?

Mr. Andy Fawcett with Selenium, that is right. It turns out FinancialForce was driving their entire CICD process by using Selenium to sign up developer accounts so that when they kicked off a new build they had a brand new org that they could end up building in. So they ended up running so many CICD jobs that they actually brought down the sign up pod. So really good news for me because I ended up getting a job with Salesforce as a result. I ended up working for, Salesforce AppCloud.

I mean Salesforce platform. It was actually AppCloud when I joined and, yeah, spent about five or six years there. Got this got to work with Karen, an amazing team, and I will actually just say that you know, the work that we did and the time I spent there is still probably some of the best, time I had in my career. And so it's just lovely to be here because all of you are on a journey that, you know, at least for me started started back then and it's it's really neat to see what everyone's done.

I actually wrote about, my experiences with this. I think I've got a little bit probably more emotional than I should have. Probably wrote a little bit too much, but feel free to take a look at it because, you know, there is a lot of hard work that went into different things and, it was very neat. I actually just very quickly will say I'm actually at a much smaller company now, like going from Salesforce to a company of about a hundred and fifty is is a pretty dramatic change, but still building tools for developers.

So I work it now at a company called RapidAPI.

We have, API marketplace with, tens of thousands of APIs in it that you can subscribe and use, and it's very exciting. And if you happen to have your own API, you can list it there and actually make money off of other people using it. It's pretty cool. We also provide services that do very much the same sort of thing in the context of the company that you work. So we make it easier for you to find APIs where you work at. That's what I'm doing today.

But you might be wondering that, alright, so I haven't actually been in the Salesforce DevOps ecosystem or the Salesforce ecosystem now for almost two years and in our line of work a lot changes in two years. Candidly, I don't actually have the domain expertise that you all do any longer here in the DevOps world, but, last couple of years is thinking about how we may make products that people use. And so very much still a part of that. In fact, Jason your talk actually really resonated.

I very much believe product needs to be more involved in the act of creating, releasing, and building software than ever before. And so what I really intend to talk today about is shipping the product strategy. And so I want to kind of orient everyone around this in this idea of what is product strategy, why is it critical to what we're doing and, you know, probably a few things here related to Salesforce and the journey along the way. In fact, what I plan to do is actually talk about all of the things I've learned over the last almost decade, mostly through mistakes made, but also through, some successes as well.

So the one thing I will say is this is not a product strategy one hundred and one. It was supposed to do a line through it, so it's not doing it all what I intended it to do.

I have no like if anyone here knows me, like I don't actually sometimes believe I know it all what I'm talking about. So this is not a product strategy one hundred and one class, it is literally just my lived experiences that I'm going to try to relate to everyone else, and try to try to share with you all. And so I'm going to start off, doing this by actually sharing with you all how I have come to define product strategy.

And I have never, honest to gosh, never Googled product strategy to find out what the definition is. I I actually was thinking about this before thinking like someone is going to do this and they're going to call me on it. So this is my definition and so I'm going to walk through it and it's my definition based on what I've seen, what I've experienced and so forth in life. So there's really two parts to it, the way that I look at it. Product strategy defines how the product supports the company vision and is brought to life through product objectives and initiatives. So there's really two parts to this. The talk and everything else I kind of walk through today is going to be broken out into these two parts.

The first part again defines how the product supports the company vision. That implies that the company's vision is actually really important here. And so we're going to talk a little bit about that. And then the second part, and this is I think where most people spend the majority of their time, is that the product strategy is brought to life through product objectives and initiatives, I.

E. The roadmap. Right? Everyone wants to know what's the roadmap. Roadmap is exciting. It's all the stuff you're doing, but it's only one part of what comprises and makes up the product strategy.

So I actually want to start with this by show of hands, who here actually knows the vision or it can be called the mission statement, but the company vision of the company that you work at?

Alright, so I mean maybe a little more than I thought. Okay, how many of you would be willing to stand up and actually recite it by heart? No, you don't have to. Here's Salesforce's company vision, to empower companies to connect with their customers in a whole new way.

To me, after having spent five six years at Salesforce and seeing the journey it was on, this resonates a lot. Like everyone here has heard about like customer three sixty, right? This idea of knowing the full three sixty degree view of your customers.

And so Salesforce is a company thinking about how they empower other companies to connect with customers in a new way that makes a lot of sense. I get it. I also want to highlight rapid APIs to empower developers to create transformative software applications. So clearly you cannot have a vision statement unless you start with the words to empower. That's what I'm taking away from this. To empower and to empower.

Now when I look at these vision statements, I think they're they're great, right? There's nothing wrong with these vision statements, but one of the things that I've come to realize is that if you cannot see how the work that you're doing, if you cannot see how the product you're building connects to and advances your company's vision statement, you've got a problem.

May end up being that you don't quite understand what you're building. It could be that you are building the wrong thing, it could be that the company itself doesn't appreciate or understand what or why you are building it. And so understanding how you define your product in the context of the company vision is really important.

And so this is what we want to avoid and I will say I have met with engineers and PMs and executives and others and I've seen this exact same look minus the monocle.

Like I've seen when I've talked to people about things that we're building, I've seen that look like, I don't quite get it, Wade.

So that that is a problem. When you're talking about what you're building and people can't get it because they don't see how it connects to the larger picture, something's wrong.

And so this is where just being super I'm going to be very vulnerable in in front of a bunch of random strangers here. So very very, humbling experience. Like this is actually what I consider to be the number one failure I had at Salesforce. And that's that I didn't know for a long time how to define the product that we were building and how that supported the company.

That goes back to this first sentence here. It was very, very hard to do. So what happens when you can't do this? There ends up being I think a lot of unanswered questions, things that are just really hard.

And so like I was actually talking to Karen a little bit about my first review, we actually called it the app cloud developer experience before it was Salesforce developer experience. But in my first review with with Marc Benioff, which was as scary as you can imagine it being, you know, there were a lot of questions that were hard to answer, the whys. You know, what is it you're building? Why are you doing it?

Why does it matter? If you cannot track what you're doing and be able to articulate it back in the context of of the larger vision, it's really hard to explain this. Now I think this group here gets it, like, and what was so fortunate for me is even if there were times that it was hard for me to articulate why this was important, so many people intrinsically and inherently got it because they had been dealing with the pain of not having some of the tools, not having some of the capabilities required.

But that still doesn't take away from the fact that if you cannot do this it's going to be very hard. And so when I consider then my journey as I came to rapid, I actually really wanted to make sure that this was not going to be the case. So again, look at this as like a case study. Rapid of course is a much much smaller company than Salesforce. So what that means is the stake of having people not understand how our product advances or supports that vision is much much higher. We're not just talking about maybe missing headcount or some awkward La Limas or internal conferences at Salesforce.

You know, we're talking about the viability of a business, of the ability for us to actually build things, that are important to us. And so we spent time really thinking like, okay, we have this vision of empowering developers to build transformative software applications. What does that mean? How do we think about our product like that?

And so we ended up going on a journey. Now, the thing that I want to highlight is in some cases and in this case as well, it doesn't really matter how you make the sausage as long as the sausage ends up getting made. There are lots of ways with which you can go about doing it. The way that we decided or I should say I decided is we were going to step back and we were going to try to define some fundamental principles that guided how we thought about our company and what we were doing.

And so this is before we really thought about how to define the product.

So we started with things like this. What we're building is for developers. Our users are developers.

We may sell to people who are not developers, but the people who use our products are developers. That is a very important principle that we decided upon. We also decided we are building one product. We are not building a product for the enterprise. We're not also going to build a product for let's say self-service product led growth oriented approaches. We're building one product and again that one product is built for developers.

It's an API first company. Now for us that's pretty easy. Rapid API, you'd imagine it's probably going to be an API first, but the product itself needs to be expressed through an API.

So that was another principle. And so we add these things on, open platform, you know, we're going to meet developers where they live. If any of you have ever tried to change, by the way, the behavior of a developer, you know, good luck. You're you're not going to get very far.

You you kind of have to show up where they are. And then we were going to really try to reinforce this idea of a virtuous cycle that as things start to go a little bit faster, it would reinforce into itself. So we started with these principles and again you might all choose different principles, but what we found with these principles then is it ended up setting a bunch of guardrails for us. It ended up helping us to define what was the system that we were operating in in the context of the product that we were building.

And so from there we ended up then actually trying to then define our product in the context of the product vision. And so here's where we landed, equip developers to make and use API's better.

It might seem a little understated and, you know, that's actually purposeful. Many of you don't really know me and so forth, but like for me it's not about fancy grandiose language and verbs. Clear, concise, say what you mean and then go go build it. And so this this really ended up resonating with us.

It worked in the context of the principles that we had defined and as you'll see in a moment, it ends up really helping to then reinforce the vision that we had had. So, breaking it down, equip. What do we mean? Well, equip means to provide.

We give tools, we give services, we do things to enable, to empower.

Who? We already established, the developer.

What's the context? Well, you know, when you're thinking about building empowering transformative software applications, guess what? That could be a lot of different things, like there's no context to it. We are contextualizing it here specifically to a particular realm. In this case it's APIs. Why? So that they can make and use APIs, and of course that last part meaning enable them to do it better.

So again, this is just a case study in thinking about it. And so once you've done this, you can now look at like can we bring this back together, right? So we had a product vision before, excuse me, a company vision and now we're trying to make sure that we can define the product in the context of that vision.

So, what are we doing then at RapidAPI? Well, we equip developers to make and use APIs better to empower them to create transformative software applications.

So to me this is really important because now when I talk to an engineer, when I talk to a product manager, when I talk to someone in our sales organization, I can help them to better understand what is it that our product is doing and why is it doing this. And I can go to anyone working on any part of our product and I can better show them how what they are doing connects to the mission, the vision of the company. I'm missing a slide.

All right. Well, the thing that I was going to highlight is the problem, and I mentioned this before, the thing that I truly do think was one of my biggest failures at Salesforce, particularly when we're getting started with Salesforce DX, is I didn't have that layer of the definition to contextualize Salesforce DX to the larger Salesforce mission. How was Salesforce DX enabling Salesforce to empower their customers to better serve their customers. I already forgot that. I swear this slide would have made it much easier for me to remember it, but but that but that I think is a is a really critical point, right? So really need to make sure that you you can do that step.

Now part two is again where most people seem to really focus and that is, you know, everyone wants to know and everyone likes to talk about, you know, what's the roadmap? What are you building? Right? One of the most fun, things that I got to do when I was at Salesforce is to be part of the release readiness.

Is that what it's called? The release readiness video, right? Like, and get the Yeah, release readiness live. Like, that's exciting talking about the new stuff.

And so this is really important and I wanted to highlight a couple of things here as well. So I wanted to start first with a fictional company.

Not sure what happened there.

Okay, fictional company and talk a little bit about how you can have the most amazing roadmap in the world and not actually deliver what the company needs you to build. Okay? Fictional, promise you. This is just for, just to tell a story.

So let's consider this for a moment. So you've got a company with a vision, you know empower your customers to make them more customer oriented, whatever that vision might be.

But if you cannot define the product that you're building in the context of that vision, what's going to happen? Well, let's say you've got a roadmap. Yeah, you're building a bunch of stuff and We'll just take this quarterly. So Q1, maybe, just maybe, let's assume best intentions and everything like here is possible. Maybe what you're building seems like it actually is going to support that vision. That's pretty cool. But you have no way of defining, no way of double checking, no way of reinforcing, no guardrails to make sure that what you prioritize, what you build, what you do actually continues to bring that product closer to what it is that the company needs.

And so you go along and you have no context for which to make changes, to adjust, to learn. And so what happens and you can probably see where I'm going with my incredible build here, is that you slowly start to drift. Now, the thing that I want to highlight is this, in this fictional company you've got some of the best engineers, the best product people, the most customer obsessed people in the world.

You still end up building the wrong thing if you're not careful.

And so roadmaps are awesome.

New product capabilities, new product features are awesome. But if you cannot explain or if you cannot think about or cannot adjust what it is that you're doing in the context of the larger company vision, you will build the wrong product.

Alright. So really what I'm saying here is that a roadmap isn't a strategy. A roadmap, the objectives, the initiatives, the work that you do is part of the strategy, but it is not the strategy in and of itself.

Now with Salesforce DX, we had a pretty great roadmap. In fact, despite what I will say again was my failure to be able to actually articulate this product in a better way, I'd give us a B minus for getting it right. May maybe on a different day, a C plus, maybe a B, I don't know. But like we did pretty well.

And there are some things that enabled us to do it. And I'm going to actually, even though it's an anti pattern to build the roadmap without the right definition in the context of the product strategy, there are ways to get it get it right. And for me it comes down to the people. And I swear Karen, I didn't just put you on here because you're here today, but like your commitment to customers and listening and advancing it is a big part of it.

But for for this story, I wanna actually highlight two individuals in how having the right partners can end up actually making up for the lack of a strategy or a bad product strategy. So this gentleman right here, Jim Wunderlich, If any of you saw like Dreamforces early on or things, you probably got to see Jim. Jim was our principal architect and here's kind of the story and how I would outline it. We didn't really have an initial product strategy and idea as to where we wanted to go with Salesforce DX.

What instead happened was kind of what I said before, we had bad PR and we were having issues with sign up pods. And effectively what happened is it became Jim's job to figure out how do we solve the pain that we at Salesforce are feeling because people are doing unnatural things on our platform to make things work because it was hard. And so Jim approached this not from a product strategy perspective, but from an architectural strategy perspective. But he did a bunch of things I think really right and I have long said that Jim would have made one of the best PMs.

Please don't tell him I said this. Jim would make a great product manager because of the way he approached things. And what he did is he met with a lot of ISVs and a lot of customers to understand what it is they're doing and why. Where was it bad?

Where did it hurt? What was going on? And so all of this came together into something that he called and wrote and called Project Janice. Project Janice basically became a white paper that Jim put together about all the improvements that can be made in the platform to make teams of developers and to be candid, most of the teams of developers at the time and probably today were ISV developers much like Jason had talked about this ISV approach.

How do we make them successful? How do we solve some of the problems and the pains that they're feeling?

Now, one thing I want to share and this is something I learned really from a lot from Jim is the customer isn't always right and actually they're they're often not. Here's the beauty about having an architect like Jim who's been doing this for a long time is he didn't care what the customers wanted. He really didn't. What he wanted to do was solve the pain, solve our pain and do it in the most effective manner possible.

And that is actually a really powerful blueprint by the way to go solve things. And the result of it is, he didn't come back with incremental improvements. You've all probably heard, the story like Henry Ford if you had just listened to what customers wanted he would have designed a faster horse instead of the car. You know, like let's be honest, if we had listened to I'm not going to say anyone in this room, but if we listened, basically, we would have seen incremental improvements on change sets and maybe Apex with a with a fewer few less limits.

Jim's vision was different. Jim wanted to actually get to the source of what was what was happening, what was wrong. And so by him not necessarily trying to index on what the customer wanted allowed him to actually leapfrog and do quite a bit of innovation. The thing that I wanted to highlight here is Jim also did something else that I highlighted earlier, but he did it as part of this architectural strategy is he outlined the principles by which we were going to make these changes.

So if anyone saw like some of my Dreamforce presentations earlier when we introduced things and things like that, I ended up saying a lot of things that Jim defined. Like, he's the brains behind the operation. But his vision was this, it was gonna be source driven. We were gonna enable source driven development on the platform, make it easier.

We're gonna build these things that were ephemeral environments. It didn't need to be long lived. It didn't need to last so long that it became messy and dirty. Right?

Such that you ended up having to use selenium to script new dev orgs in order to drive your CI. It needed to be packageable, needed to be open and standard, and it needed to support teams. And so these were the principles that he outlined that enabled us to take many many many teams and align them to a common vision. And again, we didn't have that product strategy.

While I would say this is an anti pattern, I think it still is why we ended up doing pretty well is because we had an architect that actually did a lot of this work for us. So I just wanted to highlight that this is, you know, again, I highlighted that for rapid API, I walked through this exercise of principles. I was just following Jim's playbook. Jim Jim outlined this in terms of how he defined what Salesforce DX would end up being and it's a great practice.

So I actually encourage all of you to do something similar.

This other gentleman whom I don't have a picture for him because for some reason he doesn't have a single picture on the web, and so I assume that's by design so I was not going to go and put a picture of him in front of something that might live on the web. But his name is Scott Musson and he was the engineering partner that I ended up having. Everyone knows what true to the core is, right? Show of hands, how many of you think that, product teams at Salesforce start by focusing on what everyone's asked and true to the core and go from there?

All right. No comment from me. But, I will say though one of the things that is again, I think the reason why we were able to build a roadmap that was so effective was because Scott had a commitment. Now you hear a lot at Salesforce, trust is our number one priority.

And and honestly, it's one of those things where, you know, when you enter Salesforce you're like, it can't actually be the case, like this has got to be some kind of crazy thing. It's actually like a fundamental cultural principle at Salesforce. Trust is our number one priority. And so the thing to highlight here is that when you can have a product leader and an engineering leader aligned, fundamentally aligned together, great things can happen.

And one of the things that, Scott and I were both committed to was not necessarily true to the core. What we what we talked about on teams and Karen hopefully will back me up here is this idea of true to the platform. Because what we felt is that over the years too many of these little paper cuts, these little things that are annoying. Right?

These little things that should be easy but weren't crept in. And so the idea was we were going to be committed to solving for these little paper cuts. And again, a gratuitous opportunity to use Karen's picture. A great example of this, who here remembers the metadata one program and does anyone still use the metadata coverage report?

It's been a couple of years for me. I don't every day. Okay. This is one of those commitments to true to the core.

This is one of those things that can end up really helping to ensure that you deliver a roadmap that is valuable. This was us saying that for for for us to be committed to the principles that we outlined, we were going to have to do some hard work and enable people to be successful. So for context for those that aren't familiar with this, what this program was about and what this coverage report was saying is that anything that you do inside of an org should be expressed and expressible as text. Now why is that important?

Why what does text matter? Why does it why it is important that you can do that? Well, we've all heard today us discuss version control systems and guess what it operates on? Doesn't operate well on binary files, it operates on text.

And so this commitment was if you can do something in the UI, if you can if you can configure something in the org, you should be able to express it as metadata or data that you can then extract out of the org and then use as part of your build and deploy system. And so this is one of those commitments to that true to the platform that I was talking about. So what are these two examples saying here? Said a good team can really make up for a bad product strategy.

And it's true. The reality is though, I got very lucky to be partnered and paired with a really, really good team, like world class team. Not everyone always has that fortune and can be that lucky. And so that's why I really encourage you to be thinking about, not skipping that first step which is to define the product in the context of the vision.

Okay. So still on this topic of roadmaps, I wanted to highlight and capture a few other things that I think are really important.

This is the best North Star picture I could find.

North Star visions are critical. And when I talk about a North Star, I'm talking about what is it that you aspire to build in the next three to five years?

Now it was funny as I was thinking about this, thinking three to five years, wow that's a long time. And I was like, that's actually a normal delivery cycle in Salesforce sometimes.

These things are hard, they take a while.

But North Stars are critical. You have to know where it is that you want to go, right? But you also need to make sure that you have very clear objectives, and I also put the word in here a few. The more you try to make things complex, the more you add to what it is that you're looking to do, the the more opaque, the the more difficult it's going to end up being.

Because at the end of the day, you're going to have to be able to explain this to to to colleagues in a room, to a team that you're working with. And so in your roadmap, I I truly believe you can't have too many important objectives. Everyone always says like, if everything's important, nothing's important. You have to choose the things that are important and make sure that they're they're clear.

I also really, really believe in this idea of decentralized decision making.

And again, Karen and I were reminiscing. Who here does anyone remember work dot com right at the pandemic where we were like, we're going to help you all get back into the office and two years later we're still not back in the office. Karen and I had to become experts in things we knew nothing about very very quickly and she was reminding me that I think one day I was like, you know, hey, we need to know how to do health attestation reporting so that, when you go back into the office, you know, you're following all the CDC guidelines, like think can you can you figure that out? When you when you're working with a team, when you're working fast, you can't centralize decision making, discovery, things like that. You need to be able to move and decentralize it. Let other people, figure out all the hard stuff.

The last thing is is I truly do believe that in the context of roadmaps, you need to be thinking about urgency as well. Why is it that you are prioritizing the things that you're doing? If they are that important, you should be acting on them and and with urgency because really your prioritization ends up becoming the things that you focus on and that you end up building. One other thing that I wanted to talk about too is that change is hard.

I remember and I and I contend to this day too that throughout the Salesforce DX journey, at least my part of the journey, everyone wanted us to move faster. Get more done faster. When are you going to release this? When are you going to release that?

I actually believe that if even if we had been able to deliver faster, all of your ability to absorb that change wouldn't have been able to do it. And so it's also important with roadmaps to consider the cost of change to the customer as well. And so I will say that like Salesforce nailed this early on really really well. And sometimes Salesforce gets criticized for it, but when you're especially in the context of enterprise software, I don't see any other way to do this.

The first is the v2 mom becomes a very nice way to crystallize thinking and to clarify objectives and how and what you're going to do.

The three major releases per year, I actually think is about as fast as most companies can absorb change. Now maybe it can be faster, maybe slower. Certainly like in the context of Heroku, we saw, you know, developers in particular able to accommodate change a little bit faster. But it's important to be thinking about in the context of urgency as well as the ability to manage change, how often you should be thinking about building a roadmap and deliverables within the context of that roadmap. I'm gonna give a couple of examples of why I think having longer iteration cycles enables you to basically fix things before they become too bad. And so I'm going to give three examples of things that we got wrong initially with Salesforce DX.

Force dot com IDE. Does anyone remember this? Remember the old Eclipse tooling? Yeah. We had this idea that we were going to create a native version of the Eclipse tooling specifically designed to work with Salesforce called the force dot com IDE.

I am so glad that we ended up fighting the fight that we did to switch over to Versus Code. Remember the context here by the way. This is like twenty sixteen.

The relationship Microsoft Salesforce, I actually don't know what the relationship is today. It's like a frenemy thing that keeps moving back and forth.

But the internal desire to actually take a dependency on a product built by Microsoft was very low. But I think it's really proven to to be a good, good a good thing that we did that. This is an example of us starting off and iterating on something and deciding to make a change. Your roadmap will change and actually being able to iterate, get feedback and then change, you know, at the time may seem dramatic, may seem drastic.

Oh my gosh, all this effort. We hired an Eclipse developer. What is he gonna do? Like, these are these are things that are, like, important at the time, but it's important to afford yourself the opportunity to make those changes.

The second one was our first CLI. Marc Benioff did not say that by the way. That is that is not a direct quote, but I know he was thinking it even if he didn't say it. So everyone today knows the SFDX CLI.

It's built on Oak Cliff and or maybe you don't. I'm sorry. I'm making some grand assumptions here. Oakcliff Oakcliff is, the open CLI framework.

And really what that means is it's very well aligned to, like, how Heroku had been building a CLI and really affords a lot of opportunities for extensibility, you know, getting things by default and so forth. It's a very sensible plan. When we first built our CLI, the very first CLI we built, it was not aligned to the Heroku CLI. It was a brand new native binary called AppCloud.

In fact, I was telling Karen like the first review I did with Mark, I actually demoed Salesforce DX. Again, it was AppCloud DX at the time. I demoed it using this AppCloud CLI.

Very fortunately, we did not release that. We started building it. We got some partners to use it and realized that this is not the path forward. We switched. We went and we built on top of Heroku's CLI, and that was a good thing.

The last is kind of this example and I kind of alluded to this before when I ended up saying that if you only listened to what your customers were telling you, you'd oftentimes do the wrong thing. And actually, we started off in a path where everyone, I'm assuming, or hoping knows what Salesforce functions is. It's this idea, it's a serverless offering where you can end up using multiple different run times with your own code. You You can end up running it elastically at scale.

It's connected to your Salesforce data but it gets you outside of the Salesforce org run time. Right? You don't have to use Apex in order to do it. But for a long time, we worked really hard to try to just think about how do we make Apex better?

How do we make it run faster? How do we make it run without, you know, with with less limits? How do we take Apex out of the runtime and let you run Apex elsewhere? And I'll contend that we were actually not try not solving the actual problem.

What we needed to be able to do was allow people to write the code that they want and run it in the context of the work that they were doing it in Salesforce. And it's taken us a lot well, I said us, I'm no longer at Salesforce. It took a long time. Right?

Salesforce functions probably started four or five years ago and it's the right thing to do. And so again, this is just another example that I'm trying to give that you may not get the roadmap right initially. You may might do the wrong things. What is important though is then to be able to pivot the change, as you go.

So, a little snarky way of saying sometimes you'll take a step back before you make a couple of step take a couple of steps forward. That's that's okay. That's that's normal. I wanted to share a couple of things that based on all these learnings and I'll say again like things that I would do differently today, if I were to start over, that journey at Salesforce are some things that I've implemented and do it at rapid that, you know, you might find interesting.

These are these are some of the, this is some of the culture. This is this is some of the things that we're trying to build into the company so that we stay on track with respect to our roadmap. We have a couple of of things that we do every single week in order to check against this. One is we've we've instituted something that's called a product intake.

Product intake is you meet with your customer success and or support team, whichever one you have, every week to understand what what is coming in, what are the features, what are the bugs, whether, you know, feature requests, what issues, etcetera. Very important for you to end up staying connected to that pipeline of that information.

We also end up bringing all of the the leadership together in r and d into a weekly ship room. It is not a status update. Do not do that with your whole company. That would be a very bad use of time.

What it is is it's an opportunity to highlight risk and to derisk. It is really an escalation path for teams. What is blocking? What is gonna prevent us from being successful and dealing with it immediately?

We also have implemented some monthly things where, again, this facilitates the rhythm of the business. A demo day where we can celebrate all the things that we're doing, showcase it. Things change fast. You want everyone to be on the same page with respect to what it is that you're doing.

We also meet with the executive team every single month because they're our key stakeholders. Remember, what we're building in the product is connected directly to the vision of the company. So we want to make sure that everyone, in the executive team knows exactly what it is that we're doing and why.

Every quarter, we end up doing basically a product roadmap summit where we present our our plans. What are we going to release next and what are we going to release into the foreseeable future?

Now, where I work today, we use OKRs. You know, OKRs, v two moms, BPMs, they're all the same thing. What are your objectives? How are you measuring against those objectives?

And how you know, where are you in your delivery? So we review, our OKRs quarterly and then every year we end up doing a refresh. So these are just some great ways to make sure that you're staying on track with respect to the roadmap. And again, that what you're building, the product you're building is actually connected back to the vision for the company.

In summary, I'm only eleven seconds over at the moment, but in summary, the the two things, like, again, this comes back to my definition of product strategy, but I think these are these are pretty valuable things to be thinking about. The first is make sure that, you know, you can define how the product supports the company vision. If you can't make that connection, I suspect something something is off. And then the second thing is, you know, you bring the vision to life through the product objectives and the initiatives that you define.

That again, that's your roadmap. So with that, thank you very much. Appreciate the time.

Oh, come on. The first round of applause was so much better.