---
id: "workshop:adopting-the-product-model-in-the-public-sector-introduction-to-the-product-model"
type: "InnovateUS workshop"
title: "Adopting the Product Model in the Public Sector: Introduction to the Product Model"
url: "https://innovate-us.org/adopting-the-product-model-in-the-public-sector-introduction-to-the-product-model"
date: "2025-01-29"
duration: "60 minutes"
language: "English"
instructors: ["Lynn Overmann","Ann Lewis"]
recording: "https://www.youtube.com/watch?v=t9JzZZFryXI"
transcript: "automatic, from the recording"
source: "InnovateUS (innovate-us.org)"
licence: "CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/), as stated on innovate-us.org"
---

# Adopting the Product Model in the Public Sector: Introduction to the Product Model

InnovateUS workshop · 29 January 2025 · 60 minutes

How can public sector organizations modernize IT to focus on what truly matters—achieving better outcomes? The answer lies in shifting from traditional project management to the product model approach. While project management is about execution, product management is about defining the right priorities and delivering meaningful results. In this two-part workshop series, you’ll discover how the product model can transform IT development and acquisition in government.

## Learning goals

- Learn the foundational principles of the product model and how it can reduce cost and risk

- Identify the key differences between product and project management

- Discover best practices and real-life examples of the product model in government settings

- Gain practical tools to integrate the product model into IT development, acquisition, and implementation management

- Sign up for part 2 [here](https://innovate-us.org/putting-outcomes-first-in-government-it)

## Speakers

- **Lynn Overmann**, Executive Director, the Beeck Center for Social Impact + Innovation at Georgetown University
- **Ann Lewis**, Former Director of Technology Transformation Services (TTS), U.S. General Services Administration (GSA)

Recording: https://www.youtube.com/watch?v=t9JzZZFryXI

## Transcript

Automatic transcript of the recording: names and terms can be misheard, and the times can be a few seconds off. Each time links to that moment of the video. The transcript alone: https://innovate-us.org/adopting-the-product-model-in-the-public-sector-introduction-to-the-product-model.txt (plain text) and https://innovate-us.org/adopting-the-product-model-in-the-public-sector-introduction-to-the-product-model.json (every segment with its start and end second).

**Lynn Overmann**

[0:00](https://youtu.be/t9JzZZFryXI?t=0) I think just one piece of information that may be helpful, I have been a public servant my entire career and have been lucky enough to be in and out of the federal government but have also worked at the state and local level and deeply love that work and super excited to see so many people from so many places across the country. I'm also very excited to be here with my dear friend and

**Ann Lewis**

[0:20](https://youtu.be/t9JzZZFryXI?t=20) colleague Anne and I will hand it over to her so she can say hello. Thanks Lynn. Hi everyone, I'm Anne Lewis. As Ben mentioned, I was most recently the Director of Technology Transformation Services at GSA. Before that, I spent about 20 years in the tech world before getting into government handling some of the same challenges that we see in government so have a lot of perspective to bring but also deep respect and gratitude for civil servants at all levels. I found when I was working in government, I got the opportunity to work with the best people on the projects that really matter and so we hope that this presentation will be helpful and useful and that we can continue it in a couple of weeks based on your questions and feedback. Awesome, next slide please Ben. Okay, so why are we all here? I think we probably all knew why we were here but we did find this fun statistic that we wanted to share with you from the Standish Group Report that between 2003 and 2012, about 94% of all federal technology projects over 10 million dollars failed. I suspect if somebody read this study, we probably have not made a huge amount of progress on that failure rate and we have all heard lots of stories, some of which we will share with you today.

[1:34](https://youtu.be/t9JzZZFryXI?t=94) This is the problem we are fundamentally trying to tackle and while it feels overwhelming, the product model we genuinely believe is the path forward to try to solve this pretty significant problem where we spend obscene amounts of money and don't actually get working technology products at the end of it. So you've probably seen, worked on, been a part of, experienced some of these really large complex technology projects at the federal level, state and local level and sometimes we're talking about a call center, sometimes we're talking about a benefits management system, sometimes a data migration, sometimes a really complicated project that everyone just refers to as a modernization. So let's think about what these big technology projects all have in common and then we'll talk a little bit about how we currently think about solving these challenges and then some suggestions for different ways moving forward using the product model. So for many of these really big projects, and I'm talking tens of millions of dollars, hundreds of millions of dollars, sometimes billions of dollars, usually they start with a requirements gathering process that takes a really long time, like months or years, and where a collaboration between civil servants and vendors try to build this giant requirements document to try and think of and anticipate every possible thing that people might want to have built.

[2:53](https://youtu.be/t9JzZZFryXI?t=173) And typically what this ends up yielding is a really ambitious project scope that tries to solve too many problems at the same time and doesn't actually check with the users of the systems to understand, is this the right problem to solve, is this the right problem to solve first, and for whom. So there's an extensive requirements gathering phase, but no one has validated assumptions about what the project goals are with users yet, and typically not until a few years down the road when tens or hundreds of millions of dollars have been spent. To structure this work and fund it, agencies have a tendency to put together really big projects with long contract timelines, and then even if the project successfully delivers what at the start of the project the goals were, typically the work takes so long that by the time whatever it is ships, the world has changed up from under what user needs have changed, the technology ecosystem has changed, how much things cost changed, what people care about has changed, and so even in the successful cases you end up delivering work that is outdated from the beginning.

[3:59](https://youtu.be/t9JzZZFryXI?t=239) I've often heard of these projects being vendor-led, so a group of civil servants will be assigned the work and will run a procurement process, bring in one or more vendors, who then sort of take over. Often everybody has good intentions here, but they use tech speak that civil servants don't understand, they tend to drive decisions from a technology-centric approach, and you know, I'm a technologist, I have a degree in computer science, I've worked for Fortune 500 companies, I have 20 years of experience in the field, I guarantee you that the solution to your benefit system modernization problem does not start with like blockchain or an experimental database, and yet depending on who you have in your teams and how you're managing them, that might be where the conversation starts to drive, which then can make you feel alienated or disempowered. So there are a lot of characteristics here that folks with good intentions and the right goals have, but sometimes somehow everything seems to go sideways. So with that, I will pass it to Lynn

**Lynn Overmann**

[4:58](https://youtu.be/t9JzZZFryXI?t=298) for an example of when this happens. Awesome, next slide please, Ben. Everyone loves stories to bring this home, so we, this is an actual state, we changed the names to protect the innocent. This was a state effort that was launched in the last 10 years, and it was intended to modernize their Medicaid system using the project model. So the project model is what Anne just described, with the extensive requirements gathering, the long-term contracts, and some of the other challenges. So the state issued an original contract for about 171 million dollars. After two years, the vendor delivered absolutely nothing. The state had to cancel the contract, rebid, got another vendor. That second vendor went 200 million dollars over the initial budget, took twice as long to develop a system as was originally contracted, and they launched that system after this two-year delay. Despite the fact that the system itself had failed, 123 critical tests and 285 of those tests haven't even been performed. So not surprisingly, when the system launched, it failed. And it actually ended up being worse than the 25-year-old system that the modernization effort was intended to replace. And the state had to solve the problem by bringing in actual human beings, hiring 150 temporary workers to actually work through the reimbursement backlog, or else they were at risk of losing some of their federal funding. So this is kind of a worst-case scenario. I wish I could say this is the worst-case scenario, but we have enough examples of similar projects like this where it is, alas, not a unique problem. So these are the things that we're all trying to avoid, and let's actually now turn in

**Ann Lewis**

[6:46](https://youtu.be/t9JzZZFryXI?t=406) to how we can start to do it better. Thanks, Lynn. Next slide, please. All right, so how many people here have been involved in a big technology project like this? Raise hands. Just kidding, we can't actually see the hundreds of you all at once, but I'm assuming it's most people. Most agencies and people I know working in the federal or state level have worked on, been in charge of, had to clean up after, had to deal with projects like this. It's very common. In fact, we think it's the default. We think this is what happens most of the time with large implementation projects. Next slide, please. So the good news is you can use the product model to deliver better services to your constituencies even if you're not a technologist. So throughout the next coming slides as we start to talk more in depth about the product model, for folks on the phone who are not themselves technologists, so Anne mentioned her 20-year history and her computer science degree. I am a former public defender and history major, and yet I would feel very confident using this product model and would encourage everyone on this call to consider themselves in this position as well. So we're going to talk a little bit about why you can run these teams effectively and run this process effectively, whether you are a technologist or not, and this is something that every civil servant I think can and should be doing. So next slide, please, Ben. Okay, so at a very high level, and obviously we're going to dive into some of the components of this in a little bit more depth in the coming slides, these are the key strategies that you can and should pursue to make technology successfully deliver for the people you are serving by building things in the right ways at the right time. And there's a key component to this that is, there's kind of two pieces of this that I would say are overarching and go through all of these steps. Step one is having an internal team that is empowered by leadership to own the product vision and be responsible for the product strategy. Having that consistent team overseeing all of this work over

[8:48](https://youtu.be/t9JzZZFryXI?t=528) time will ensure that delivery is ultimately successful. Start small is really important. I think it's the antidote to the spend two years trying to figure out every possible component that you need and then try to figure out how to put the pieces of the puzzle together only to find five years in that you got it wrong. If you start small and you start most importantly by deeply understanding your user needs, you will help prioritize, you will be able to build something quickly and then you can test that thing with your users. So we do have center users here as second, but really it should be at every step of the process. You should be working and testing your products with your users. Two reasons, one, they are who you are trying to serve and two, testing products with folks early on will surface problems, bugs, et cetera, that you can solve much easier earlier in the process than when you're much further down the road. Work iteratively, so build something, try it with users, fix what doesn't work, try it again. So a lot of this is rinse and repeat and we've got some great examples of how this works. And then deliver regularly. And there's two pieces to this. One, if you're constantly shipping products that have been developed with and tested with users, you're delivering them value right off the bat and helping ease their process through whatever service that you're trying to deliver. But two, if you're an organization where you have to think about things like change management, you have to think about customer experience or you have to think about things like how are my frontline case workers or staff workers who are going to have to engage with this technology as part of their job adopting this technology. Regular delivery and responsive delivery to their needs is also going to help with uptake and change management over time. So I will hand that back to Ann for our next slide.

[10:40](https://youtu.be/t9JzZZFryXI?t=640) Thanks, Lynn. So let's talk about how this compares to the way that we currently work, which we're calling the project model. So as I mentioned when we first kicked off this call, typically these large technology projects involve a process of gathering requirements that takes months or years before work starts. You don't have to do that to get to a successful outcome. You can start with a problem statement and say here are the problems we want to solve, create a functional prototype that typically only takes a few days or weeks to create because it's a prototype, and you can test that with users. You can start yesterday. And so what that helps you do is it helps you understand who your audience is, listen to them, they feel gratified that you're listening to them, and you immediately get this critical feedback that can help you craft and adapt your goals over time so that instead of trying to make a list of all possible solutions to all possible problems, which is very expensive in terms of time and money and risk also, you can start to hone in iteratively on exactly what problems your users are having and the most pragmatic and often cheapest ways of solving them. So that's one big difference between the project model, aka the status quo, and the product model. Another thing that we've seen pretty often here in these large technology projects that go sideways despite everyone's best intentions is that people assume that people and by civil servants and vendors assume that you're done when you make a giant list of all possible requirements and check all of them off. But as we all know in practice, that leads to solutions and launches like healthcare.gov or the FAFSA situation or the Medicare example that Lynn just shared. Somehow even if you try and make a list of all possible things and get them all done, it doesn't actually lead to the solutions that make sense and empower your constituents. So we're going to suggest that done actually means that you, meaning your small nimble empowered team and your vendor partners, verify that the features and the systems that you

[12:43](https://youtu.be/t9JzZZFryXI?t=763) have built work from the perspective of your users and you do this every couple of weeks. You work iteratively and you redefine what done means in terms of does it actually work for your users. This cuts out a lot of the unnecessary complexity. It takes the burden of getting everything right off of everyone involved because you don't have to guess or hedge or make a list of all possible things. You start with does this work for you? If yes, great, go on to the next step. If no, listen to the user feedback and adjust. And so what's absolutely critical to make this work is the empowered internal teams. You don't have to be technical to do this work. You just have to be willing to raise your hand and say I want to figure out how to map out the solution space by talking to users. I want to take feedback and work iteratively. I want to show up to these demo meetings that are happening now every couple of weeks instead of every couple of years. And what this does is it gives you control over your delivery vision and your strategy. And so when you think about how to structure projects like this, instead of thinking about it as well, we build a thing or we procure a thing, like thinking of websites and systems as if you were to go out and buy a car or an airplane, well, we got one and now we have one. Let's, you know, we're done. Let's not worry about it. And then the world and the needs shift out from under the thing and then all of a sudden you have a problem, you have a system that doesn't work that well.

[14:04](https://youtu.be/t9JzZZFryXI?t=844) And then typically people say, well, we need to modernize. That's the problem is that the system is old. It's five years old. It's 15 years old. It's really old. It doesn't do the things we want to do anymore. We need to modernize. And then you typically work with your budget managers or sometimes appropriators or depending on how your budget works to get a big chunk of money for modernization and say, well, we need the biggest chunk of modernization money as possible to guarantee success because we need to make a giant list of every possible thing that could happen and throw money at it. And as we know, as we've experienced over and over again, this doesn't work. So we need to shift away from that project model that tends towards big builds and then system neglect for a few years. And then another attempt at a big build, this time labeled modernization. We want to shift away from that into continuous funding, assuming that this system that you have built and are constantly adjusting, fixing bugs, developing new features, adapting as the world changes. with a continuous funding stream that is funding capabilities and not one-time builds and one-time modernizations. And then another difference between the project model and the product model is in the current status quo way of doing things, vendors take that giant requirements doc, try to make sense of it, try to comply literally with what's being asked here, because typically we contractually bind our vendors to do this, but not every possible thing can be anticipated ahead of time and the way that it's written out will sometimes constrain implementation and technology choices that your vendors will make in ways that have unintended side effects that don't actually work for you or for your users or for the set of systems that this system lives within. And so in partnership, the small empowered teams in government agencies need to work with vendors to build ongoing capabilities in an iterative process like

**Lynn Overmann**

[15:49](https://youtu.be/t9JzZZFryXI?t=949) Lynn just described. Great, I just wanted to jump in quickly because I've been keeping my eye on the chat and some of the questions that I'm seeing we will try to tackle at the end, but I do want to do a little bit of a teaser, which is we are hoping to collect some of the kind of burning and top of mind questions from you all here to help shape the next webinar that we'll be hosting. And one of those obviously like really thick and hairy questions is this, how do you shift the funding model? And what do you do if all you have is a giant chunk of funding? So just wanted to give a call out that we recognize that what we're talking about right here is describing the model and what we were hoping to drive towards in the second webinar is going to be how do we help you answer questions from getting from where you are to where you would like to be with this model, assuming that we're actually persuading you. And we'll hand it back

**Ann Lewis**

[16:43](https://youtu.be/t9JzZZFryXI?t=1003) to Anne. Thanks, Lynn. Yeah, definitely aware of some of the funding challenges that you're mentioning in the chat here, and we're hoping to bring in some folks from the federal and state level who have found creative ways of reframing and restructuring their budgets to accommodate or at least support or at least not prevent use of this model that we know delivers better outcomes. Next slide, please. So let's talk about an example, a success story of this model in action that was, I think, one of the most important projects to come out of the Biden-Harris administration, and that is the story of Direct File. If you haven't heard of it, I recommend Googling it right now because unlike most of the projects we work on at Civil Servants, this project got a lot of positive press, to everyone's surprise. So Direct File is a free tax filing product that Americans can use to file their taxes. It was built by the IRS with a small and interdisciplinary multi-agency teams of folks from IRS, the United States Digital Service, and 18F from TTS, the organization I used to run. And I just wanted to give a shout out to Marisi Vinton also, if you're listening or if anybody knows her, fantastic leader of this project.

[17:59](https://youtu.be/t9JzZZFryXI?t=1079) And so I'm telling the story of success here of many other teams and folks who deserve all of the credit. So the Direct File product was something that started with an idea, and it was able to be delivered in a short number of months by using the product model. So here's how it started. You could imagine a scenario that used the project model that started with reading all the different parts of the U.S. tax code and trying to write down all the requirements for all of the different ways that the tax code can vary based on an individual's various kinds of statuses, eligibility requirements, income, businesses, et cetera, and even more complexity for business entities. And then you could imagine spending six years writing that requirements document and then handing off to a vendor who then sort of started to create a public sector version of Intuit and then ran out of funding halfway through. This is what happens most of the time. What this project did instead is they started with a small team. They started with one user, and they mocked up or created a functional prototype of a very specific scenario, a simple scenario from the tax code and from a user perspective. And then they put that prototype in front of the user, just one user to start out with, and said, what do you think about this? Could this work for you? And immediately they got feedback from the user that the way the form structure didn't quite work and they weren't sure what this thing meant. And because they got that feedback early on, they realized a tax form is a single page that encapsulates this giant branching tree of possibilities, and people are not sure how to navigate that tree. And most people are not experts on tax law, and they shouldn't be to be able to file their taxes. So the first thing they figured out was they need to figure, they need to identify on that form for that one scenario, that one category of users that they're starting with, what's the most confusing thing on the form for most people? And then what they do is they turned that question into a question that they asked the user up front. Does this particular scenario apply to you? If yes, fill it in this way,

[20:02](https://youtu.be/t9JzZZFryXI?t=1202) if no, fill it in that way. And they started to build on that approach of figuring out by talking to people and looking at data to understand what the biggest challenges were, what the biggest barriers were to filling out this tax form that affected the most people. And they were able to create a guided assistance web form that helped anticipate the majority of confusion that people had and guided them through the process. So instead of you as a user navigating all possibilities of the branching tree of tax code, it would take you by the hand and say, here's the path that you need to go down, getting your feedback and input every step of the way. So what they did here, that's a great example of the product model, is they started simple. They started with, here's something that we think might be useful, slap it together into a prototype, put it in front of a person, get feedback back, test your hypotheses as the civil servant in-house team. And then they realized our initial idea wasn't quite right, so we'll readjust based on user feedback. They readjusted, readjusted the prototype, put it in front of a few more users. And they kept iterating in this way every week or so until they had something that was useful to 50 users, then useful to 100 users, then useful to 1,000 users. And eventually they got to a functional prototype that turned into a real system that was able to launch in about a year, which is kind of amazing in terms of, like, if you think about how complex tax software is. So what they were doing here is they were talking to users, they were iterating regularly, they were also shipping, meaning you take your software that just lives on your laptop and you put it, you ship it to production or put it in a place where people can access it and use it. And you do this regularly so that the pushing out of new changes is not a big, scary, complicated thing. It's just a regular practice. It's a muscle the team builds. User research guided this whole process, and by that I mean talking to users individually, face-to-face, talking to users at scale, getting feedback, seeing user behavior, and paying attention to it, understanding what it means, and using it to drive decisions.

[22:05](https://youtu.be/t9JzZZFryXI?t=1325) And so in total, this cost not a billion dollars, not 200 million dollars, but about 2.4 million dollars to build total, launched, helped people fill out their taxes in a lower stress way than they anticipated, and then got a bunch of headlines like the U.S. government ships a piece of software that doesn't suck, which is pretty good given, you know, the general state of the world here. So I think that this is proof that this model can work, and it can work in complex, high-stakes government environments, and it can work in a way that is led by civil servants who don't have to be technologists. They just have to accept and drive these iterative processes and the processes of talking to users and making decisions based on the feedback that we get from users.

**Lynn Overmann**

[22:54](https://youtu.be/t9JzZZFryXI?t=1374) Awesome. Thank you, Anne. I will also, I think another piece of the puzzle here that we didn't explicitly talk about was part of the user testing was also load testing the system. So they also did, you know, the best system in the world, the most beautifully designed system in the world won't work if it crashes when people access it, and so that was another component that we did not directly mention, but I think is important, particularly as you're thinking about rolling out services that you expect is going to be in high demand right off the bat. Also super excited that the new administration announced that they're going to keep DirectFile open for another year, and it will be open to a total of 25 states, so definitely encourage folks to use it if it is in your state and let us know how it goes. So Ben, can we do next slide, please? Great. This is something that I am super excited about as somebody who has worked in government many, many years who realizes how hard it is to stop projects, and the product model is actually quite useful in this regard as well. So we do want to highlight the other side of the coin here, which is sometimes the best thing you can do is do research and decide we should not be doing this at all. So I did want to brag on our team a little bit at the Beck Center. So we have a team at the Beck Center called the Data Labs Project. Our team works with multidisciplinary state teams to work on a problem both state teams identified, and we help them work through things like discovery, sprints, and user research to leverage their data to achieve their outcomes.

[24:28](https://youtu.be/t9JzZZFryXI?t=1468) So a couple of years ago, we had an amazing opportunity to work with a great team at Idaho, whose one-stop committee, which oversees their workforce programs, which are intended to help Idahoans who are looking for jobs, had for seven years a chief goal of theirs to create a common intake form, put it online to more effectively link their constituents to the array of non-profit service providers who could help them and address their unique job situations. After seven years, but just after a couple of months with the Data Labs program where we helped them run a discovery and user research sprint, we quickly all collectively realized that each partner organization that was involved in this effort who would have been pushed into this online form had such vastly different intake processes and operational workflows that not only would making an online intake form not solve the problem for the end users, it would actually have created more burden both for the people we were trying to serve and also for the non-profit agencies that were trying to help them. So based on this sprint, Idaho actually decided to kill this idea and stop the project, and they took the money that was allocated for the online form and distributed it differently in a way that they think actually helps their constituents more effectively. So the beauty of, and I think to go back to kind of the original, you'll hear us harping on it over and over again, the downside of the huge retirement requirements process and the many, many year projects or contracts is that you don't get to this question of, should we even be building it soon enough? And oftentimes when it gets to the stage when you're using the project model of, oh no, this is actually not what we need, you're several million dollars in several years in, you're in a pretty iron bound contract, and you're kind of stuck with the decision of, do we pull this down and have to go explain to our leadership and our constituency that we've spent

[26:29](https://youtu.be/t9JzZZFryXI?t=1589) several million dollars on and have gotten nothing? Or do we stick with this vendor who has perhaps delivered us something that isn't actually working and hope that if we do this another round with this vendor and continue on this current path, that we can somehow pivot and make this work? So I do want to say like the art of getting to know is also frankly something you can use as a selling point, particularly if you've got skeptical leadership of, hey, let us just take a crack at this, let us do some user research, let us do an initial discovery sprint, and we'll come back to you and we'll have a much better sense of being able to tell you what the viability and feasibility of moving forward looks like. And we'll be able to come back to you and tell you we can build you something in two weeks that's going to start to

**Ann Lewis**

[27:12](https://youtu.be/t9JzZZFryXI?t=1632) tackle this problem. So next slide, please, Ben. All right. So let's just go over some of what we talked about today. Adopting the product model over the default project model way of managing these big implementation and technology projects in particular, it gives you continuous ownership over your progress, goals, and outcomes. You don't have to make a big set of guesses in a requirement stock. It takes months and months to do, hand off to a vendor and then wait months or years to see progress or to see validation of your assumptions. You can start seeing validation of your or invalidation of your hypotheses early, and then you can redirect as needed. So this allows you to understand what's happening at every single step of the way and also de-risk the outcomes of your

**Lynn Overmann**

[28:00](https://youtu.be/t9JzZZFryXI?t=1680) project. Yes. And another, as you've been hearing, the immediate feedback, the value add of that is massive, not just for the product itself, but for all of us who have worked in systems where even with the most empowered team ever, we all have leadership we need to report to. We often have oversight or congressional or legislative bodies who are interested in what we're doing. We have reporters. We have people who are FOIAing us. You will be so on top of your project if you're using the product model because you will be constantly aware of where the project is, how it's going, any challenges and plans to address them. So not only is it a really effective way to actually ensure that what you are building is good, you can also communicate quite easily and

**Ann Lewis**

[28:45](https://youtu.be/t9JzZZFryXI?t=1725) cleanly to the folks who you know are going to be asking you questions about it. Yep. And with this immediate feedback and better control gives you better control over risk and budget. So you don't have to make big, big, big investments and then find out every couple of years whether or not they're successful or not, and then explain it to whoever appropriates your budget. You'll be able to tell immediately what's the level of risk, how am I spending this budget, am I spending this budget on problems that actually are the right problems to solve, and if not, you can redirect

**Lynn Overmann**

[29:13](https://youtu.be/t9JzZZFryXI?t=1753) early. Awesome. And I talked about this a little bit, so I'll just touch on this briefly. I will say my experience has been when we use the product model, your leadership gets super excited about it because they are used to the product model or the project model where, you know, they get this giant appropriation, it goes off into the ether, they forget about it, and they keep their fingers crossed, and they often only care about it when it's gone sideways. This collaborative partner between leadership and implementation teams and users helps leadership stay engaged and get excited about things. It gives them things to talk about, and also making sure that your leadership understands actual user needs, which oftentimes they may not be in direct communication with users, frankly, I think makes for better overall Introduction to the Product Model in the Public Sector

**Ann Lewis**

[30:24](https://youtu.be/t9JzZZFryXI?t=1824) I believe that the product model gives better outcomes and a lower long-term cost because you're starting with something, you're ruthlessly constraining complexity and starting with something simple that you've validated works. And then you add to it only as you come up with ideas for features that you are sure work for users because you've asked them and you've tested. So this is always going to be cheaper, lower risk, faster, better than anyone's attempt, no matter how smart they are at predicting the future and making a list of every possible thing that's going to happen. It's just by design of the process.

**Lynn Overmann**

[31:01](https://youtu.be/t9JzZZFryXI?t=1861) Yes. And then I want to go back to Anne's example of buying a car or buying an airplane. I think the most important thing that it's really critical to walk away with this is buying software or procuring software in a standard process is not like buying a car. Because when you buy a car, they deliver it, it should work, and you're kind of done with it for the next few years. Software can and should be, particularly when it's customer facing or constituency facing, needs to adapt constantly over time. It is not static. It has to grow and evolve and change along with needs. And that is another reason why having internal capacity and having that overarching product vision and strategy is so critical because that team is the one who can see those needs and ensure that they're being met continually over time. Anne has already given great examples of why dropping in chunks of money every few years to try to update things both doesn't work and is incredibly expensive.

[32:10](https://youtu.be/t9JzZZFryXI?t=1930) As you can see, we are obviously massive proponents. We've drunken the product model Kool-Aid and are going to continue to talk about this with other folks.

**Ann Lewis**

[32:21](https://youtu.be/t9JzZZFryXI?t=1941) I think we wanted to go next slide.

**Lynn Overmann**

[32:26](https://youtu.be/t9JzZZFryXI?t=1946) I mentioned this earlier, I have to confess, I got out of my skis because I was excited to share with you that we want to use your feedback to shape our second webinar. But we do want to explicitly share this survey link. We're hoping that we have convinced you all that the product model is the way to go about doing business. That honestly feels like it's the easy part. I think the more challenging thing we're all going to have to grapple with together is the different scenarios that you all might have of where you are now and how you can start to make progress towards this approach, given the constraints that we know you're inevitably under. So if you could please fill out the survey and share some of your questions or feedback and then of course, I think at this point, Anne, are we ready to open up the floor for questions that we can try to tackle in our time left?

**Ann Lewis**

[33:13](https://youtu.be/t9JzZZFryXI?t=1993) Yeah, sounds great. So if you are feeling extroverted and you don't mind talking in front of a few hundred people, feel free to share your questions here. If not, please put them in the survey that we shared. We're going to try to adapt the next session.

* * *

Original page: https://innovate-us.org/adopting-the-product-model-in-the-public-sector-introduction-to-the-product-model · Licence: CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/), as stated on innovate-us.org