 Next up, we're going to talk about digital product management and why it's critical. We heard that mention, it's a big topic in the digital space. And to help us navigate that, I'm delighted to introduce Mark Boldman, who's a senior product manager at ServiceNow with specific responsibility for CSDM outbound product management. His experience and expertise, he's been a product manager, IT for IT strategist with an enterprise architecture background and previously an IT for IT strategist at HPE software and product manager at True Enterprise Architect at Dell and honorable discharge from the US Army in strategic warfare systems. And in this session, Mark will review the definition of digital product and highlight why digital product management in uniquely different than current product management or IT management roles. So it is different and I've already seen some questions about how. So your topic is right on point here, Mark. And Mark will also explore requirements for the role in needing proficiency in both classic product management and technology management skills. So a warm welcome from the open good place for Mark Boldman. Welcome. Nice to see you again, Mark. Thank you, Steve. Great to see you again, too. It's been a little while. It has. Over to you, sir. All right. We can see your slides and we can see you. Excellent. All right. So we kind of went through the agenda already. It's really the defining of digital product that got us here. What the digital product manager needs to kind of deal with, complexity that they're dealing with and also the lifecycle and how do we scale your organization around this sort of concept of digital product management. And I wanted to kind of start with this perspective of there's this digitized world versus digital world or digitalizing world. There's a number of terms here, but there's kind of two halves of the equation that we're dealing with. And Charlie touched on a number of these things, but primarily IT has been involved in the digitizing of internal work, the things that you do inside a company in order to automate work like HR or finance or even building products that eventually ship to customers. That has been where IT has grown up. A lot of the frameworks and the things that you do in IT are centered around that kind of thinking. Then we have the digital world where the products and the services that are being created today are now accessed directly by customers, partners, vendors. So the interaction between people on the outside or the embedding of technology or IT within the products that are provided to customers are also happening. So there's really two halves of this equation and the language and the acumen is quite different. As Steve kind of went through my background, I was thinking, wow, I've transitioned myself between the right side having a product to sell to customers and the left side, which is to automate processes for companies like Dell. And what I find is that you're having to change your vernacular. You have applications on the left, but you have products on the right. And so this has become quite an interesting space to bridge that together and identify where can we learn from one another? Where can we apply product management acumen in IT or take IT acumen and put it into the product? Because what scares me about this whole idea of having IT embedded in every one of my products and how they connect, and it opens up the door for vulnerabilities being hacked to be able to steal my data, to take over my products and do something bad with them. So the two worlds need to be able to converge in a big way. And here at ServiceNow, we talk a lot about making work better for employees. And that's been a big part of our platform is to serve the employees and make the customer experience within the company. Even if you're going to work for a company, the experience for IT tools or internal tools is not as nice as what you see in the market. And so we want to converge that experience and make it better on the internal company use cases and the internal company products. So with that, what we have is a definition here for the classic product management. And that is really the idea of having that function or person in the company that deals with the full lifecycle. It's the product development, the business justification for the particular product that you want to develop or put in the market, forecasting what that product is going to look like and what the next version is, understanding the pricing for that product. We don't necessarily have a pricing component on internally consumed products, but think about your HR systems and the fact you have to pay licenses for every employee or every HR person that uses that system. There is a cost. There is what we call typically showback in understanding the cost per employee or cost per HR person. And then we have to also deal with marketing that product internal or external. So the classic product managers that are, if you've ever been a product manager, you'll understand that you need to get your product into the market and let people know, whether it's paying for a TV ad or word of mouth. If people don't know about it, they won't buy your product. So what happens on the internal side though, that's kind of interesting. And just a quick story, when I was at Dell, I was part of an internal standards team that had various products that were consumed internally. So that was sort of my job at the time. And I hired a product manager or a marketing person and to be able to understand how to understand my consumer. We were technologists. We weren't product people. We weren't marketing people. So when we hired a marketing person and they had product management background, we learned about this and we were starting to apply those kind of practices for internally consumed digital products. We didn't call them that, but that's kind of what they were. And digital products are everywhere, but there is a key distinction that we want to make here and we'll get into that in a minute, but there are smart watches that basically have applications on them. They're a platform into themselves. There's smart cars. There's smart jet engines and smart ovens. And you'll see a class of products that are old school that now have digital components to them, IT embedded in them. And I think my favorite use case here is these engines because the Boeing aircraft itself now is very digital, right? They're basically a flying data center and they're supported by on-ground data centers. And the products that they would OEM from an aircraft engine manufacturer would come in, they would bolt it in historically and then they would fly. And if it broke, they would call the supplier. Well, that relationship is sort of pivoted because there is now instrumentation on those jet engines to be able to provide feedback and also predict maintenance cycles. And the supplier of the jet engine maintains a lot of the technology used in making these predictions and supporting that particular aircraft. So now the relationship isn't necessarily an OEM. There's a living engagement with the supplier to be able to make sure that engine is functional for the life of the aircraft. And that's another thing too because the aircraft will be in service for 30 years. And so all of this technology that's embedded has to be taken care of and supported for 30 years or more. Things like 747s have been around a long time. And if you're not familiar with it, Boeing creates an IT shop to support every single model. And so the IT behind the scenes or the IT embedded now in the products is here for a long time and you have to take care of it over that whole life cycle. That's an important part of the digital product now that IT is sort of embedded in there. And so when this all comes together, there's a product manager plus application manager is what makes a product manager, digital product manager. And it's these two key areas when you're thinking about classic product managers that understand markets, the financials, whether we're making a profit or not, even internally, does it make sense to build our own or buy or partner with somebody else like in the jet engine business? We also see that product managers don't have a lot of IT acumen, classic. We don't teach every product manager what IT is all about or how to manage code, right? These, this whole DevOps kind of area, we don't teach them today. And the application manager, the interesting thing from a classic application point of view from an internal management is they know pretty well the technology. They understand how the technology is used internally but often we have that situation where a project comes in to create a new application or put it into service and then the project team is disbanded and everybody goes off to the next thing. And there's been no sort of carry through with the next version or consistent management or team that's aware of how to support that particular application over its useful life cycle. So those are two things that I wanted to mention because when they get combined, when you understand sort of the IT context and the product context from a classic definition, then that is where your digital product manager sits and you don't need to be a technical expert on all things that are in the product. But you do know if you're creating an aircraft engine that the mechanical and the software, folks have to work together in order to deliver that and product to the customer. So this is basically from the shift to digital product white paper where we went through and defined what a digital product is. And the key thing with this is that we went through the process of defining certain elements that define what is inside a digital product that may be different than classic product. And the first thing we defined was it concludes a service offer that defines what a contract is with your consumer. And the contract, it can be very loosely defined like a promise or it can be a very specific thing that's got financial implications if you don't live up to your contract. In IT, we call it class of service, right? You've got this tiered gold, silver, bronze or whatever tiering you want to do. There's a contract to keep those particular applications up and running for this, for the same level. And a contract with a digital product like the car, there's warranty period. There is a right to repair that comes into the particular product that you might own as a consumer. So this contract needs to be understood when you're a buyer and I like to use my digital oven. When I built this house that I'm in about two years ago, it came with a oven that had IT embedded in it. And do I upgrade my oven every time like I upgrade my phone or do I incorporate those particular features as they come out from the company? Is it upgradable? And what happens when my Wi-Fi protocol changes to Wi-Fi 6? Can the oven still work? So those are the concerns that you have to have in the contract that the consumers is the key part of that. It's delivered as an instance and the instance could be a device, a physical thing or a user that has access to a shared resource like Workday or something like that. And that's based on the offer or the contract. And some of these are entitlements like if I go to work for a company, there's an expectation that I should be able to access the HR system for requesting things from HR or finance department. So there's a contract that could be entitlement based on where you work and the expected job that you have. But it also turns into physical things like the jet engine situation or smart watch. So you have an asset in your hands. And again, what's the contract? If you own still the original iPad, you can't upgrade it anymore to the new operating systems. It's almost like as Apple has decided not to continue to support upgrades so that forces you to get to the next product. So that's part of your contract as a consumer. Each traditional product instance has a system containing technology resources and usually in primarily software. And that's the other interesting thing is that products don't live on their own and it goes back to something Charlie said about, nothing is really autonomous. There's connections to everything. You have a supplier that provides something you embed like the engine or do you have a dependency that engine needs to be able to connect to systems and download data so that it can perform the next analysis of maintenance requirements. So these are all connected in some way and you see that in your house. I don't know how many people have a smart house. I have about 70 devices in my house that are all connected. So it sounds like a lot but boy even my printer, my oven and I have a watch. Everything you buy these days seems to have a Wi-Fi connection. Your door lock, your doorbell. Maybe consumed within an organization or external and that's the key part of this is that we want to treat internal use of products the same as we do external use. The only difference is do you have a paying customer versus do you have an obligation with employees to be able to provide these services or to automate the factory as it will. So we don't want to make a huge distinction and difference between those two worlds. The only difference really is the consumers is somebody that sits beside me in the organization versus an end customer where that might be paying for something. And may have dependencies on other digital products. Obviously when you look at the system the fact that these things are all interconnected all networking is going to be ubiquitous across the globe. We've got companies now blanketing the earth and connectivity. So everything is connected and so dependencies are now the norm versus the not the norm. The other thing that we want to also manage is the human and machine interface as well. Most organizations are built on very connected applications or very connected products. The problem that you have is understanding those connections and we want to treat those human and machine interactions just the same. The main difference is that you don't necessarily know the person on the other side of the API call but if you go out one more layer there may be a person and that's got to be understood and you got to treat those API calls just as frugally as just as well as a human interface because even back in the day I don't know if anybody's worked with old mainframes and screen scraping technologies human machine interface was sort of the same in a lot of ways. So we don't want to create a huge difference in how we manage those interfaces. And as a digital product manager you want to be able to understand and pitch your product and this is internal or external if you're looking for investors in a new product idea or get more money. Internally I'm one of about 80 product managers within service now and every product manager is trying to get resources for their product. They need to be able to describe why they need those resources and why for investment. You need to understand the technology trade-offs of your digital products if you're going to basically leverage a technology that might be a dead end or maybe there's no skills for that particular technology you have to look at that. Again you're not the going to be the technology expert but you'll have to listen to your technology experts as a product manager and understand those trade-offs. You need to understand the business aspects with if it's an important internal strategy to improve HR or maybe it's the manufacturing line or maybe you're going to sell off the manufacturing line and maybe that's not a strategic investment area. So when you're looking at these investments you have to be able to weigh that from a market perspective even if the market is internal. And last is really the successfully scale you need to be able to to look at the full lifecycle you can't basically stand up up a team build the product and forget it. You got to look at end of life and most people don't think about that. You know these products are created that's the exciting time you put it in the market and it's out there but what happens when you want to dispose of it? What happens with all of those dependencies or dependents on that digital product? So you've got to be able to cut all those ties effectively or notify them when you're upgrading or replacing with a new model. Why does it matter? And I'm just going to build this out just in the interest of time. I know we're starting to get close. Why does it matter? Is every company is a technology company in some way whether it's a distribution channel or your betting technology. It's very touchless as kind of what Charlie had on. In the physical product management world it's very static. You have to deal with replacement parts or whatever but it's very slow but digital world is very very fast and digital scale is very exponential. You can put a product on the App Store and on the Apple App Store and have millions of users potentially if it's a good one because a word of mouth and the fact that it's a great product. And it does require some IT knowledge not everything but enough to be able to understand where are my resources where are they needed how do I automate things to get the next version out. You have complexity there that you don't have in physical products and in that interdependencies and they are longer lived as products that are getting embedded in somewhere else even this microphone I'm using is a digital product and there's IT embedded in this so it's got to be upgraded and I don't I don't want to replace my microphone every year. And so agility is really the key here. And they're complex I'm not going to get into this one but you have products that have contracts with other products and that dependency chain is quite long and you never know where the end is but at the end of that dependency are internal customers or external customers and we don't want to treat them very different with our definition. So that's key is defining this in a way that we can apply for ubiquitously across the old school application or maybe service portfolio management if we transition to digital products everybody's on the same page whether it's an internal external and we can use the same systems to manage these and upgrade products or do the end of life type of planning. And I just wanted to share this one quick view. This is a prototype of a digital product managers dashboard that I put together based on my own requirements I want to see what's happening from a planning build what's going on from a building perspective how things are being released and deployed and operated and providing service to my own customers and all of the elements of that digital product whether they be risk and compliance issues problems in testing right the next version of my digital product or even funding next year do I have the same team or can I get more folks to do more things. And so the digital product is on the left hand side and the offerings that I have are sort of that critical component that I need to be able to aggregate and understand that big picture and drill into these things if I see something wrong if I've got regulations that have changed and I have a new requirement from a GRC perspective governance risk and compliance perspective I can address it or a lot of a lot of customers complaining I can address that as well. And the last slide I want to kind of leave you with is really each product evolves over time and in the digital world you can put more I would say functionality into the code then in the mechanics and in the classic thing that I like to bring up is I don't know if you read about this but Tesla basically had a problem with their cars they would not break in time according to what relations had called for. So they did a patch of the software which made the brakes more aggressive and therefore pass the tests required of their product to be sold. And so the idea that you can evolve these products from a simple idea and upgrade them likewise Tesla is upgrading their driver assist package to a self-driving capability the only reason they're able to do that is the hardware and is there already they're just upgrading the software to be able to perform new tasks that weren't really there when they originally came out with that car so that iteration that constantly improvement is now available for almost all digital products that have some sort of embedded code and also you scale these things right whether it be an internal idea that for a new product you put on the market you try it you scale this as the product gets bigger and more complex so from a founder team team of teams all the way to an enterprise level where now you're just one of 80 products like in my case here at service now and you're all dealing with buying for resources but now you're planning across a much broader set of products both internally used and externally used so there's and that comes from our DP Bach library so I think that's the last question slide that I have and I think I'm about at time as well I think I'm right right there as well so I don't know if you have time for questions or Steve you want to get to the next session but I'll leave it up to you you have done a great job keeping us on time Mark and a great run through there's a lot of a lot of stuff to get through there so I appreciate appreciate your thoughts and sharing your experience there and and some customer some some potential customer feedback I've enjoyed the service now ads on TV in the in the in the golf coverage by the way so they're always fun yeah and we we just launched the Willy Wonka ad campaign as well so we're automating factories as well as a customer experiences fun well we are going to hold the questions for the for the panel I don't want to steal anyone's thunder there so we will next up for us is a five minute break so thank you for taking us to that and see you on the panel Mark in the meantime a warm round of applause for Mark Bobman thank you Mark