Agile Product Development: How to Develop Hardware Like Software
00:23 Hello and welcome to today's Analyst's Insights. Agile Product Development. How to develop hardware like software. I'm Colin McMahon and I'll be your moderator. Today I'm joined by Ryan Martin and Steve Dertien So let's get to know them a little more. Steve Dertien is the Executive Vice President and Chief Technology Officer here at PTC. He is responsible for corporate technology strategy across the portfolio and solution offerings. Steve also leads the PTC Reality Lab and drives our SaaS transformation strategy.
00:55 Ryan Martin is a Senior Research Director at ABI Research, covering new and emerging transformative technologies, including Industry 4.0 Digital Transformation and IoT. He leads the firm's manufacturing, industrial and enterprise IoT research efforts. Okay, but that's more than enough for me. Time to turn over to Ryan and start with a really basic question. What exactly do we mean when we talk about Agile? Thanks, Colin and hello everyone.
01:25 When Agile Agile started more than 20 years ago with the Agile Manifesto and it's now commonplace in software development to allow it to be more responsive to market conditions and customer demand, it's different than the Waterfall method, which is typically known as sequential, pretty document heavy around a pre-defined project or goal. Where Agile differs and is defined largely around a few core values and also 12 core principles.
01:55 So those values they agile value is individual or process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. So it's not to say that one is bad, but Agile is typically believed to be better. And the reason is for it's usually drives continuous or always drives continuous release of software delivery.
02:28 The key metric, so prioritization capability for short or predefined achievement milestones that incorporate change even up until the end. And that's largely very different. It has to do with breaking bigger projects into smaller management sprints, prioritizing face to face interactions as a key lever for efficiency and then importantly, closing the feedback loop on some of these big projects that are broken down into smaller bite sized pieces.
02:58 And so this has been happening in software for some time, but it's just starting to make its way into hardware development as an approach. Steve, how are you seeing software development principles of Agile being adopted by companies who build and engineer products? Thanks, Ryan. Thanks everybody for for being here today. You know, if I were to say, if we look at our our audience members today, I don't think there's going to be a single customer here or or anybody in our space that would say they're not agile. I mean, like quick and maybe iterative, but if you said, hey, as it's applied
03:31 to product development, whether it's in your strategy around the way that you want your products to be, for example, you know, software defined products like software, defined vehicles, you know, what we're finding is, you know, the hardware world hasn't adopted agile at the same rate and pace that the software will effectively do. You know, the principles of the Agile Manifesto really essentially said, Hey, build working software as quick as possible. And as we know, you know, hardware doesn't have that same pacing cadence. You know, code changes are effectively free.
04:01 You know, hardware changes take some energy. And so there's some certain challenges inside of that that our customers are certainly looking at in the market in general. But if you said how do we take, you know, what the software companies did, PDC included, and many others, you know, combine it with automation and DevOps capabilities like they had and then can we apply that to the engineering discipline itself, both mechanically and to the software? You know, can customers essentially make their product better? And that's, you know, that's a gross
04:32 simplification of maybe a complex organizational challenge. But as you start to think about, you know, the agile principles, you know, one of them is, you know, how fast can you make change? How fast can you iterate with a customer? You know, a lot of this is very beneficial to customers to find ways to do that, whether it's for their supply chain reasons, you know, meeting customer demand, you know, getting a product to market faster. And so that's that's pushing, you know, I would say the limits on on the current waterfall techniques that are being used in hardware, customers are essentially asking themselves, you know, is it is it possible to scale, you know, in a manner where your hardware is
05:04 built, like your software is? And so, Ryan, maybe maybe we talk about some of the trends that are driving that sort of product adoption. Yeah, the I love the notion of hardware built up a piece of software. One of the reasons that's very pertinent today is because of the pace of change and markets so rapidly changing customer requirements and key categories. One obvious example would be transportation change to electrification autonomy. The suppliers need to find faster ways to iterate
05:36 and bring a new product to customers. Need differentially brought to customers faster. Well, I mean, they're like consumer goods. If you think about companies like Nike, Adidas, even Trek bicycles looking for sustainable ways to produce products that they've produced historically, but to bring them to customers faster. And so it's really about changing and markets. It's also about an evolving workforce. So global distributed and remote teams who need to collaborate in real time and get stuff done.
06:10 Steve, you must be seeing some engineers with what's the reaction to Agile? Yeah, I think they want to do it and embrace it. It depends on the who, you know, the software people, let's just say, are generally reaping the reward. But if you said, Hey, I want to be a little bit more agile with my suppliers and the way that we're incorporating components in the design or, you know, you were saying, Ryan, in the manifesto, it's it's about face to face. And here we are, you know, virtually, you know, kind of face to face with the audience members here.
06:41 And I don't think it physically means to be co-located anymore. And so the idea of like, how can we work from a collaborative perspective, you know, globally, we can't exactly get everybody in the room. And so many of them are saying, how do we work off the same ground truth, if you will, of information? And so that's that's really led its way for us to incorporate a lot more collaboration tools into the way that we work. But you made a kind of a subtle point here. You know, if you think about the new and career engineers that are joining us these days in every company,
07:11 they're pre-wired to collaborate differently, like they're pre-wired to collaborate in a multi person sort of way right out of the gate. And so a lot of the tools and the processes, you know, that we need to do, we even need to cater to that new style of of collaboration that's there. Many of us are used to like the, the typical sequence of, Hey, I do my design Ryan here, maybe you should work on it over the night and kind of send it back to me. And nowadays that's not the expectation anymore. It's a little bit more continuous. And the reason is you want those changes to kind of compile every day,
07:42 like the idea of a daily build, if you will, so that, you know, are you trending in the right direction or not? And so there's, you know, real opportunity to drive continuity of that information as opposed to I'll use the word derivative works, right? The more copies we create and send out to the supply chain, have them work on it and then bring it back, you know, is a lot of reconciliation. And that kind of runs counter to some of the agile principles of making sure that you're able to kind of bring it all together. Ryan, One of the best ways to personify this is to show a customer example. And at PTC, we have a great customer whose name is Ocado.
08:15 I'll let the video kind of speak for itself. And why don't we roll that real quick? Grocery is a really unique marketplace. Margins are razor thin. There's an expectation around freshness, multiple temperature regimes and an immediacy to customers. Customers need their food when they want it on their terms at the right price. To the heart of our solution as a fleet of bots moving around on top of a grid, moving groceries backwards and forwards, enabling picking of groceries. And our current generation bought the 500.
08:45 It's a cutting edge piece of technology that delivers on all fronts speed, efficiency, reliability. At Ocado we don't want to stop at the cutting edge. We want to move forward. So the 600 series had a really fundamental different way of being developed. At its core, it was about using additive techniques and applying a lot of software techniques to hardware development. So fast iterations of development. We brought in software engineers to work alongside mechanical electrical engineers and that kind of mixing of minds and mixing of approaches created something really quite distinct and new to Onshape played a really important part
09:16 right at the start of what 600 is a way of bringing together people from all different partsof the organization. Being cloud based. It was a much more modern approach in terms of any device anywhere, unlocking the ability for people from non mechanical engineering backgrounds to get involved across different boundaries and enable us to do more kind of scripting and automation around the tooling as well. Features like branching emerging are really fundamental to what we're doing and allows more individual experimentation and allows more work to be done quickly without blocking other members of the team and really allows to adopt a lot of the sort of software development processes into hardware engineering
09:48 because branching emerging is really core to Software development. So those approaches around code reviews and pat programing really facilitates that kind of work. Using the more agile approach to development meant we could get bots on grids really early, we could get prototypes out that would move and actually operate on the grid, even though they weren't fully functional yet. Something that worked and showed the concept was viable and that the weight reduction was real. And that was really powerful in terms of ensuring we were confident of moving forward with the initiative. It's very exciting to see this new approach being played out to Ocado. It's great to feel
10:18 that we're at the forefront of looking at this stuff and we're learning and developing new techniques rather than simply following The route that other people have taken So Ryan, I think that's a pretty cool example, you know, as a customer, Ocado is, you know, certainly reaping the rewards of having collaboration across their team. I think, as you heard, you know, they've even implanted some of the software people right in the design side. Taking it one step further, I did have a chance to talk to some of the folks there and,
10:48 you know, even the way their teams still form around their sprints and their sprint planning, their org chart doesn't actually look like a traditional org chart in terms of, you know, who the design engineers are, who the electrical engineers are, who the software engineers are, because they have people that have multi skills and they can basically fill a need. And so there's that's basically given them incredible flexibility to kind of make a pretty innovative product like that. And some of the other side effects of that have certainly been, you know, just the attribution they can bring to things like sustainability. You know, the next generations of their products are actually more sustainable to produce.
11:20 And, you know, that's a that's an interesting little consequence of of kind of being reactive to kind of the market need that they have and the way that they've implemented it. So maybe maybe spinning it back to you. You know, I know you've done a lot of extensive research on on this and digital transformation. You know how companies are approaching the effort from your perspective and are they different in size or are they different in complexity? Like what makes it what makes it work for some and not for others or, you know, just kind of give us a perspective there.
11:52 Yeah, there is definitely an overwhelming interest for digital transformation to become part of the ethos of almost every company, because companies see digital transformation and agile approaches and innovation in general as the fulcrum for attracting, retaining the people that make their business their best. What's changed in the last couple of years is that there was a time when I was hearing it pretty much every level of the organization. They would say,
12:23 these big digital transformation initiatives, something like Digital Twin they'd say we need to have a digital twin and everyone said, Yeah, yeah, we need to have a digital twin. And at the end of a pretty long period, they may or may not have a digital twin. But what was happening is development around a technology instead of for a purpose. And now that script is totally flipped to optimize as the economic agents such that the projects that are being worked on are those that drive
12:53 immediate and ideally incremental value that builds on itself. And that's where we have come to identify time and really time to value as a new metric and KPI upon which you should optimize. And the reason is that instead of let's use the digital twin example, so instead of saying we need to build a digital twin now is we want to improve of quality, performanc eand availability of our equipment. And then by the way, at the end of connecting the equipment and you
13:25 have a digital twin and that is very much the approach to industry 4.0 and digital transformation in general today it's okay, what are the problems and how do we work back from that? And that aligns incredibly well with Agile for both software and especially hardware, because it promotes flexible collaboration change downstream when it may not otherwise have been internalized and that improves customer relations, it allows you to drive alignment between teams because instead of working on these large lofty projects with maybe a big ROI,
13:58 the kind of undefined payback period you're working on, projects that show results immediately or very near term. Ideally, those results are good, but if they're not, you get feedback and then you can pivot and react. And ideally you build scale or build value over time to get into the upper right hand quadrant. Let me at this point turn over to Colin to introduce our first question. Thanks, Ryan. Great discussion so far, guys. Now we'd like to see how you, the audience are using Agile methodologies,
14:31 so please turn your attention to the poll that just popped up on your console and respond to our first question of the day. You'll have roughly one minute to complete this question. And Steve, this question has all to do with hardware products when where companies are on the path to implementing Agile. So I know you've been talking to people a lot about Agile product development. What do you see where companies typically at? Yeah, I mean, your question basically puts us on a spectrum, right?
15:02 There are companies that may not be using agile inside of hardware. That's not to say that you're not fast or you're not, you know, adaptive to to need, but you know, you might be still embracing a, you know, a little bit of agile principle inside of a waterfall. You know, that that's the partial aspect for might be you're actually trying to do your best to at it. You know the question is you know, how far can you go And then maybe on the kind of far end of the spectrum is you're really, really embracing it, much like, you know, how Ocado is embracing it in the development of their products
15:32 and you're kind of all in like everybody from the management team organizationally, all the way down to the people doing the work. Ah, you know, kind of adapted to the entire thing, you know, incorporating it in their processes and, and kind of reaping the reward on the hardware side. My venture on this and Ryan, kind of curious on your thoughts. I think we're going to see probably a fair amount of clustering and like the bottom third ish, if you will, with a few outliers, you know, good outliers, kind of top performers in the in the upper. But let's see what kind of happens. You're curious on your thoughts, Ryan, as we got a couple seconds here.
16:04 Yeah. What I would imagine that there are a handful of companies that have been doing agile hardware development, but most probably are not that I would posit However, they probably those that have done software are probably listening to this or seeing this as saying, Why aren't we doing this yet? So I'm really curious to see what the results bring. I think we're also going to find like four companies that have kind of core products that you can all rally around similar to like what Ocado had.
16:36 You might get there a little easier than, let's say, a big automaker who's got a plethora of different options and variants and plants and complexity. And you know, that complexity curve isn't dictated by the company size necessarily because there are much smaller companies. I still have that same sort of portfolio complexity as well. And so there really will probably get into a question we get into later is, you know, where exactly did you get started? But I think I think that might in a way a little bit on some of our respondents as well. Let's see, let's see where our respondents are at.
17:06 So we have kind of a good distribution here with most that tier two level that informs. So some practice and tools are in place, but not formalized is policy. Agile has been adopted by a single or multiple teams, but it's not really coordinated. A company level. So it's like we're talking about this and we're talking about. So it seems like a lot of people have started the journey, but they're not there yet. And we've already kind of hinted at this in the conversation.
17:36 But Agile and SaaS can play a key role together. You know, they're very complementary tools. How do companies need to use both to kind of get over that hump, get over that informed hop and get into the repeatable, get into the fall organized and Steve will start with you for, for that one. Yeah. I think if you think about connecting people and having a continuity of information that everybody's working off the same way, it's no question the reason why software had a lot of agility, a lot of velocity
18:06 and so forth was because a lot of the tools that they ultimately chose, you know, were were essentially SaaS based solutions, if you will, that allowed, you know, greater connectivity of the participants and allowed them all to kind of work off the same the same plan, if you will. And I think, you know, that's certainly fueling a little bit about what our customers are doing as well. You know, they want to, you know, kind of strive and have that same connectivity that's similar to, you know, how students have it with Google Docs, for example. You know, there's no no student that you're hiring out of school these days
18:36 that that doesn't know how to do that. And it's not it's not by virtue that they weren't looking for SaaS. It's the virtue is they looked to actually at the enablers for collaboration. They looked at the enablers that allow them to move swiftly. And anywhere where you have some sort of a transformation event of manipulating data, moving it back and forth, you have a continuity problem. And, you know, so I think that allows companies to really focus on their core competency rather than on the implementation of the technology that it takes to make it. And, you know, I'll give you one one example.
19:07 I think we've all heard tried or explored Chat GPT in the last six months. And, you know, one of the big differences there is that technology is several years old. The difference was is that OpenAI essentially made it publicly accessible to all of us, like instantly it required virtually no, you know, access constraints to actually try it. And it actually lit the world on fire from a conversation perspective. And so there's some virtue in terms of being able to kind of connect people in that way. You know, Agile has no barriers in getting that information out there.
19:39 So. Ryan maybe see, yeah. Steve, let me jump in. I just need to play devil's advocate here. I've got to wonder, you know, Open AI, Google Docs is accessibility or is there such thing as too much agile? It depends on what you're trying to drive. And let me give you an example. As a lot of our systems, so are customers that make larger complex products as as those systems increase in size and complexity. You know, imagine a car just, just to use the most extreme example is very hard for
20:13 you and I to kind of keep track mentally of like all the things we need to be doing. You know, you're talking about, you know, modestly decent sized teams all working on different systems and trying to keep them coordinated. And so, you know, there is a need to kind of keep track of that. There is a need, you know, to kind of try to be agile within a space of regulatory constraints as well. You know, whether it's cyber security or safety or, you know, you go right down the list of the things that are kind of coming at our various different customers and their industries. You know, there's a reason to do that.
20:44 I think it is possible to try and overdo it. Meaning can you over automate something or attempt to do it, you know, if it's not something that you do repeatedly, I don't know that you would do that. So like when I talked about continuous integration, continuous development in software, we generally want to automate the things that we do recursively all the time, every time we want to make a change, do that. You use digital twin earlier. I don't know of a company that really has a fully fleshed out digital twin and it comes back to value proposition, like how much is essential in order
21:14 to answer the critical questions that allow you to bring a product to market faster. And if you look at it through that lens, you might decide that certain avenues or certain paths are more efficient to not go really deep technologically, if you will. Colin. I think at this time I think we're ready for a second poll question. You got it. Good stuff. So let's see if we can get a little deeper with understanding how everyone, you, the audience, are thinking about Agile. Specifically, we'd like you to tell us which aspects of Agile do you find most valuable.
21:46 Hopefully you find something valuable. The polls should have just popped up and you can please let us know. So let's go through and we're looking at, yeah, there's flexible collaboration accelerated innovation, availability and mobility, speed to market, or improved risk management. So as we're waiting for the audience to to buzz in and get our answers here, I'm kind of curious, you know, Ryan, which jumps out to you like, what do you think is the the most valuable of that list? So at
22:16 running the risk of potentially skewing the results, to me, it's when I look at all of these and today in the current macroeconomic context, it's really about time to market and time to value, especially if you are a physical product company. It's a tremendous competitive advantage If you can get to market faster, especially in certain highly regulated industries like pharma, for example, could be in excess of a year. Steve, I think has some great stats on different industries as well,
22:46 but it's really about and time to market is one is for the customers, but it's also evidence is the alignment required to do things really well to do to to to operate and perform an excellent standard is really about speed and agility and being able to react to not just customers, but also internal changes and being being welcome to those kind of any time.
23:18 Steve, what would you say? Yeah, I'm going to agree with that. I think the idea of time to market is kind of paramount. There's no company that produces a product and says, Hey, I'm going to take six years. Just just because you know that I don't I don't know that our shareholders and owners would appreciate that that sort of time. But if you said, like, how do we be more responsive? How do we engage with more people? How do we engage with our suppliers and our partners, you know, to work on what we're doing? Giving them the ability to kind of collaborate better is is a first big step. I think the rest is really managing risk, you know, and
23:50 during a lot of electronic parts shortages and things like that, you know, how do you cut over to a different supplier did actually force customers to think about, you know, how to do a let's say, a mid model change of some kind to incorporate, you know, things that were just happening because supply was tight and you start to think about how do we manage and and supplement risk in our business. You know, Agile is certainly a working method that has allowed some companies to kind of overcome that adversity that was was experienced here the last several years. And quite frankly, I think that's a behavior that will just continue to come.
24:23 You know, it might not be, you know, forced by by a health pandemic. It might actually just be forced because the supply chains themselves, you know, are are becoming tougher ecosystems to participate in as well. Okay. Survey says Well, once again, we're pretty spread here. Accelerate innovation that got 50% of our answers. Flexible collaboration, 45% speed to market 32%. So you guys didn't influence it that much. I guess
24:55 availability and mobility, only 5%. So interesting. So there's there's quite a bit of opportunity and value with embracing agile and hardware in development, like we've been talking about the good stuff, but as with anything, it's always easier said than done. So Ryan, what do you think is the biggest challenge here? Yeah, it's probably achieving. What was the response to that whole question? I'm thinking to accelerate innovation requires a pretty heavy lift, and especially
25:28 depending on the the company size and for larger companies to accelerate innovation, it comes down to really organizational change management. And often we talk about a start small scale, fast mentality, but we're talking about the changing the tools, a global organization. That's definitely a massive challenge. Steve How how do you see this playing out to customers today? Yeah, I think it let's just divide companies in terms of scale. Like I think at the larger companies, you know, organizational change management is going to be a big part of it.
25:59 And it's partly because they're going to have some other challenges at their scale, whether it's their return on capital strategy, part reuse, just the the sheer magnitude of what the impact of change. In fact, in a lot of companies that have, you know, let's say large factory footprints, you know, change is inevitable. But at the same time, like making change is probably not the most desired outcome because it costs a lot of money and in the way that they operate, whereas a customer like Ocado that we shared or many others where you know, their product is really an innovative
26:31 high tech product, that quite frankly, innovation is, is mandatory. In order for them to be competitive year over year, they're more likely to adopt and get much deeper in it faster than than the traditional organizations. At the end of the day, I don't think it's a technology question so much as it's a organizational change management kind of in a 90:10 ratio of, you know, how exactly do we put it into process and practice, you know, across the different disciplines. And I also think from a personal perspective, you know,
27:01 software people have a lot of basis to to kind of work from the community at large, kind of embraced it. And, you know, we're now just trying to figure out how do we actually take that and bring it to teams that have otherwise not really used it to that that same level. And so it's also like a transformational sort of thing for people that haven't yet experienced that, you know, from from a practice perspective. And that takes some time as well. And so I'm hearing culture size or challenges call. And if you're with a third poll, let's see what the audience has to say
27:33 about challenges. Yeah, let's do it. All right, guys, final poll question of the day. So thank you for joining with us for this exercise in democracy. This time we're shifting more towards challenges which come with any anything, any shift in direction. Specifically, we'd like to know what's been the most challenging part of your switch toward Agile at your organization. So there should be a pop up poll. Hopefully it works. Let us know. And thank you so much for your participation. So just quickly read through, Updating legacy systems,
28:03 training employees, managing your IP, ensuring compatibility with existing tools, and just the organizational change management. So Ryan, I've just listed a whole bunch what comes up most often in your experience? It's usually people stuff. People are inherently resistant to change. Importantly, also need to understand the why. So it should be doing. We should be explaining why we're doing a change.
28:33 What is the benefit that individual, the team, the group and the customers and leaders often overlook this very important last piece, which is often explaining or even starting with why to ensure that you're doing the right what so the actual activities. And today that's more important than ever because there are so many different different innovation packs or tracks, whether it's AI or Metaverse or twin
29:03 data continuity architecture, it's cloud SaaS, There's so much change. So figuring out what is the right the right part to get behind, and then making sure that you have the right people on the bus is is critical. Steve, what do you think? Yeah, I think change inevitably is one of the most difficult things, you know, when you go through it. That was true when the software team there were even people at PTC that probably said from my cold dead
29:33 hands, will I ever switch to Agile until, you know, you start to see the rewards, you know, kind of kind of be reaped by other teams that do use it. And I think that moment kind of has to kind of show up and appear. I think from a management perspective, you know, who are the executives, stakeholders that are really kind of driving that and is that associated to the business outcome in some way. So, for example, you know, if your strategy is to change to a software defined product type of company because you want the revenue stream of a recurring software differentiated product, you might have
30:05 a completely different mentality around what you want to have happen there. And that's very evident with like what's happening in automotive right now. The electric vehicles that are kind of forthcoming are leaning more and more in that direction, more so than the historical, you know, vehicles that we've all purchased as as as consumers and owners. And that in turn is saying, yeah, the software is actually a much bigger part, but we need the hardware to kind of keep pace with that software offering. And so there's a lot of executives, stakeholder management that says these things need to change because our business model is going to be
30:36 fundamentally different than better. And I think once you have some aligning drivers that do that as opposed to just Agile for Agile, you know, I think customers and organizations at large will will find ways to kind of navigate through it. And then, you know, the technical challenges that remain like how do we drive more automation and things like that are very solvable problems. We just got to narrowing on the ones that matter most to, to improve that, you know, product innovation, velocity. If you will. Good stuff. Let's see what people said.
31:06 Now they're split. Mostly we have two like 40%. here with training employees and ensuring compatibility with existing tools. Nobody thought managing their IP would be a challenge. 52% Organizational change management. That would be the biggest challenge and we have about 30% for updating or legacy systems. So now that we've kind of we've reviewed the benefits, we've reviewed the challenges. Ryan What are some of the best practices for how companies implement Agile effectively?
31:37 How do you overcome these? Yeah, you know, if I were to be hypercritical and maybe had an option after the poll question, it might be getting new tools. And the reason I mention that. So for for practical advice, I was, I heard the adage you can't manage what you don't measure. So it's super important that you measure success and that and why I mentioned new tools is that potentially it could be that maybe you need to consider new constructs or new tools, new ways of thinking to measure that success.
32:09 One of those measurements could be the amount of time that you're driving, the intended amount of value, so within a time horizon, because time. also is different for every company, also critical is that once you can measure your success, you need to validate that it really is success. So high level, it's really fundamentally about closing feedback, feedback loops. That would probably be one of the best piece of advice here to help drive alignment between teams, also break bigger projects into smaller bite size and manageable increments
32:39 that you can really sprint through, figure out what is a successful and then iterate from there and ideally build build ROI on top of it. But this probably doesn't apply wholly. So. Steve, what is the difference between companies for complexity and simple, and why would Agile matter any scale? Yeah, I think, you know, there is a variety of different
33:09 agile frameworks that are out there for companies based on their scale, right? So, so larger industrial companies might use the scaled Agile framework because as an organization, you know, they need more decomposition to work, create their org chart kind of demands it and that that's, you know, one way to achieve that. And many of our customers do do that. The question is, you know, how far down can they take it in smaller organizations might actually have really flexible teams where the team members are moving around, performing different tasks in a true, you know, kind of agile assignment sort of way.
33:40 I think ultimately the answer, you know, really lies in what are you doing that ultimately gets your product to market faster and meets the customer expectation and maybe the inverse of that too, We've all had, you know, kind of the product development stage gate you know, methodology where like at certain stages, you know, the impact of change, you know, cost money, especially in the later stages. Well, the same is true of launching a product, especially a product that doesn't meet customer expectations. And so for some organizations to actually say what should we actually stop?
34:11 You know, we if you think of it this way, most of us are not really increasing the capacity of people. We're asking them to basically produce more results for us. And so one of the best decision making tools that we could all have is the ability to say what things shouldn't we be doing, because we don't believe that they're going to have a market fit which allows you to go back and double down on the ones that you do, as opposed to just kind of spreading it out. And so I think even in the decision management process, they're running large and small companies alike and kind of take advantage of
34:42 of some of those things to ultimately yield the impact they want to have with their products and their and their customers. So maybe, you know, we've been talking for a little bit amongst the three of us here, but I'd love to get into some audience Q&A and see what sort of questions they have and you know, where that takes us. Yeah, sounds good. So thank you, Ryan and Steve for that great presentation. And now we have some time to take, as you said, take questions from our audience. So let's just say please note that the questions are in like a Q&A widget, which should be under the bottom part of your display.
35:16 So let's dive right in. So just please submit them as they come up. I see we have a couple I'm going to read this out. I can see how agile principles can be adapted for product design and development, but I'm a little fuzzy on how it's applicable to manufacturing. Can you give some detail of how you see it being done and what the benefits are? Steve, since this is manufacturing? Well, we'll start with you. Yeah, Yeah. Well, obviously it's near and dear to my heart. I mean, you can't design something that you can't make. And and so ideally, you know, we've had kind of an organizational idea of like how much can you actually
35:48 start and co-develop or make code linear in your in your process. Right. If you get advanced manufacturing sooner into the design process, you know, customers might actually understand is that achievable within the cost target? And so certainly, you know, incorporating the ability to kind of bring manufacturing up sooner has always been kind of the desired state. It's also where the most money gets spent. So I mentioned the phase gate a moment ago. You know, the reality of it is change actually costs the most amount of money. You know, when you start really impacting what it takes to produce it,
36:18 especially if you have your own factories that are producing it as opposed to, you know, commodity purchasing, if you will. And so I think, you know, being a little bit more agile to say, hey, this does or doesn't work in our process is is a big advantage. Now, at the end of the day, once you're making hardware, once you're making, you know, physical things, you know, the velocity might be different. You know, software changes are free. You can do them daily at some point. You can only put so much stuff through a milling machine to make a mold or a dye fast enough. And and so therein lies the dilemma on kind of the decision making.
36:51 So there's not a there is going to be a I'll call it a physical limitation as to how fast things can go. The key, I think, in my opinion, Ryan, interest in years is just how fast you can make that decision, the right decision to to make that choice. Yeah. To me, again, it's also all about velocity and driving alignment where we're really I think it's interesting in the medium and longer term is thinking a lot about how the collaboration model may evolve. So I could see Agile being a best practice and that's really what it is,
37:25 is about looking at to, to potential development tracks and recognizing that one is better than the other. And that's just generally what's happening with a lot of the newer solutions coming to market, whether it's SaaS or permanent cloud enabled anything, it's okay here, you don't need to have this, but over time it's going to be better than what you have been using. So you probably should. And it's just a matter of when you jump in the river where where I think this question gets interesting. So maybe taking just one step further, what the current framework could look like
37:57 is when we think about collaboration with external suppliers on a more regular and recurring basis for design development and manufacturing. So pulling in supply chain components and even third party suppliers or engineers to all collaborate in one trusted workspace is something that I think as industry maybe we're striving toward, but potentially not quite there. Yeah, I'd agree. I think the state of the art there still is to send work packages to everybody, you know. But but ultimately, you know, it might take you a day to maybe even weeks to
38:31 kind of get responses back, particularly if that supplier is responsible for. I'll just stick with injection molding real quick. You know, if you sit in the straight wall part over and expect the supplier to send you back, you know, the design as they would prefer to mold it with all the draft and things like that kind of built in like that dialog back and forth is somewhat disconnected. And so if anything were to ever change, like the rework loop is consequential and some of that and so I think, you know, for customers that are able to kind of collaborate more seamlessly there, that is, that is certainly cutting out cycle time and driving up.
39:02 I was looking for the word earlier concurrency, right? Just being able to make concurrent change and seeing that the changes even coming in the first place is is helpful. Right. Means you might actually stop, you know, adapt and kind of move it forward. And you know, a lot of that is done through verbal cues right now. But the continuity and the volume of information that we're all dealing with is is maybe one of the biggest things to keep everybody on the same page from. I want to actually underscore what you just said, because I think that concurrency is really critical for velocity and time to market, because if you think about a product with
39:32 I mean, even a simple product with like ten or 20 different parts, each of those parts is tolerance built into went into how it is manufactured and designed and that tolerance adds up. So if you can minimize it or really get rid of that, that way you're bringing product product to market much faster with really minimal change. that's a thorough answer. I appreciate that. Not passionate about the topic at all, I can tell you. All right. So we have a new one that just came in. One core principle of Agile is incorporating voice of the customer.
40:03 What are what approaches are companies employing to include voice of the customer in their product development? Right? And you see a lot of companies. So I guess I'll start with you, the voice of the customer. I mean, it's it's about closing feedback loops from products after they're designed and built. But that's the biggest the biggest emphasis right now. So as designed, as built and maintained and trying to have a constant visibility into what that product lifecycle looks like
40:33 so that future products are better optimized for the customer. But Steve, I'm sure that you've got some strong thoughts on this too. Yeah, I guess, you know, customer has a couple of different connotations here. One is, is as a supplier, the OEM that I'm doing work for might be a customer. The other is as a, you know, ultimate end customer that's purchasing a car. And so if we said, hey, as in the supplier example, just to kind of go back to it, if I can get you in the middle of my thought loop a little bit in terms of what I'm doing, you might actually understand that the requirements that you gave
41:03 me may or may not meet your expectations much, much sooner. So earlier participation, you know, frequent feedback and so forth, that kind of works when you're able to kind of speak with the same design language, if you will, gets a little bit more interesting with, you know, ultimate end customers, you know, consumers, if you will. You know, I don't know that we're exactly, you know, firing up 3D models and drawings and like, you know, saying, hey, is this what you want? You know? But the idea of being able to take that technology or rapid prototypes and things to the customer and get that feedback sooner is is certainly one of the principles of how to do it.
41:35 Now, the software teams, again, we've said this numerous times, they can more or less kind of demonstrate that daily, even do A, B testing pretty effectively. You know, the real trick becomes, you know, how do we do that? Similarly with some of the hardware scale, you know, that we would need to do to kind of get something in front of a customer sooner. I mean, at the end of the day, that allows them to kind of voice their their interest a lot sooner. And that just kind of ties into the velocity a little bit, in my opinion, in some ways. Just a final thought on this. It's kind of like a fusion of hardware and software or agile for software
42:07 and hardware, thinking of virtual commissioning type instances where virtual commissioning plays in a manufacturing context. But how about a virtual showrooming or any kind of metaverse type scenario, an application? What this goes to say is that the voice and view of the customer is becoming much more tangible in terms of closing that feedback loop. But does that still quite. Yeah, especially if you once you get into the size and scale of some of those things that you want to test, you know, anything that you can do that cuts out, you know, millions of dollars
42:39 and changes and, you know, six months of of commissioning time, you know, that that's worth its weight as well. And you know, there's still a lot of work to be done there, but it's impactful. It's really, really impactful as the complexity increases. Okay. So this one comes with a bit of a different perspective. How can I convince my manager to start implementing more agile practices into our processes. Steve, we'll start with you for this one. Yeah, I think first and foremost, you know, with the end in mind,
43:09 like what outcome do you want to drive? What outcome would be better than, you know, kind of your starting position, if you will, And if a lot of the stuff that we talked about really resonated with you today, you know, that's certainly helpful. But I think, you know, every company thinks in dollars in some sort of way. So if you were able to associate, you know, kind of that objective with, hey, we think it'll drive these clear business outcomes, even if it's, you know, lowering the bar on the impact of change, if you will, because change, you know, can be attributed to cost. But that in the mind, as Ryan alluded to,
43:39 you know, the you know, what is the impact of bringing a product to market faster. I'd say make sure that you have a compelling business case that really kind of sells the advantage. If you just my opinion, if you just say Agile for agile sake, you'll probably get a little bit there because everybody says, I want to be faster, I want to be a little bit more agile. There's nobody that would say that, you know, but you are going to need stakeholders to kind of buy in and understand what's in it For me, contribution part of it because it is different, it is definitely going to require some different behaviors out of people. And you know, some of us are reluctant to change.
44:10 And so that that's a little bit of a sell through on the management side as well. Ryan, your thoughts? I think you hit the nail on the head. The what's in it for me goes right back to the why. And I think as soon as you start talking about why we should be doing Agile versus something else, it's pretty obvious that it's in the right circumstances. But to put, you know, AB test it and, and it should be pretty clear that's the best way to do it is, is actually put and try and do some of the stuff in practice. Explain it, why are we doing it.
44:40 What's the milestone? How do we measure the success? And then if it's successful, how do we validate that and then iterate and move forward and. Right. And it might be as applicable in some of these organizations to work in a small focused area team first, you know, proving results that are impactful rather than a complete, you know, fundamental change management of the organization and, you know, kind of chip away at it through proven proven examples if you will. Completely agree. Okay. So I guess that's all the time we have for questions in today's webinar.
45:13 Once again, I would like to thank Ryan and Steve for joining us today. I would also like to thank you, our audience for tuning in and remind you that we have several resources available for you in the Resource library, including recent white papers about Agile product development and making the transition to SaaS, as well as other notable links to PTC's, SaaS Transformation and Agile Product development pages. We hope you enjoyed today's webinar and that it's only increased your curiosity to learn more about how Agile product development may help your organization compete and lead in the 21st century.
45:46 Thank you so much for joining us!