www.eatingpolicy.com
Open in
urlscan Pro
2606:4700:4400::6812:2418
Public Scan
URL:
https://www.eatingpolicy.com/p/project-vs-product-funding
Submission: On December 18 via manual from CA — Scanned from CA
Submission: On December 18 via manual from CA — Scanned from CA
Form analysis 7 forms found in the DOM
<form class="_form_15pnt_9"><input class="_emailInput_15pnt_32" placeholder="Type your email...">
<div id="error-container"></div><button
class="pencraft pc-reset pencraft _buttonBase_bxx6e_1 _button_bxx6e_1 _buttonOld_bxx6e_51 _buttonOldColors_bxx6e_70 _priority_primary-theme_bxx6e_285 _size_md_bxx6e_166 _fill_filled_bxx6e_432 _grow_bxx6e_37 pc-justifyContent-center" tabindex="0"
type="submit">Subscribe</button>
</form>POST /api/v1/free?nojs=true
<form action="/api/v1/free?nojs=true" method="post" class="form _form_11q5m_6" novalidate=""><input type="hidden" name="first_url" value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="first_referrer"
value=""><input type="hidden" name="current_url" value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="current_referrer"><input type="hidden" name="first_session_url"
value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="first_session_referrer" value=""><input type="hidden" name="referral_code"><input type="hidden" name="source" value="subscribe-widget"><input
type="hidden" name="referring_pub_id"><input type="hidden" name="additional_referring_pub_ids">
<div class="_sideBySideWrap_11q5m_10">
<div class="_emailInputWrapper_11q5m_57"><input type="email" name="email" placeholder="Type your email..." class="pencraft _emailInput_11q5m_23"></div><button type="submit" class="button rightButton primary subscribe-btn _button_11q5m_76"
tabindex="0"><span class="button-text ">Subscribe</span></button>
</div>
<div id="error-container"></div>
</form>POST /api/v1/free?nojs=true
<form action="/api/v1/free?nojs=true" method="post" class="form _form_11q5m_6" novalidate=""><input type="hidden" name="first_url" value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="first_referrer"
value=""><input type="hidden" name="current_url" value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="current_referrer"><input type="hidden" name="first_session_url"
value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="first_session_referrer" value=""><input type="hidden" name="referral_code"><input type="hidden" name="source" value="subscribe-widget"><input
type="hidden" name="referring_pub_id"><input type="hidden" name="additional_referring_pub_ids">
<div class="_sideBySideWrap_11q5m_10">
<div class="_emailInputWrapper_11q5m_57"><input type="email" name="email" placeholder="Type your email..." class="pencraft _emailInput_11q5m_23"></div><button type="submit" class="button rightButton primary subscribe-btn _button_11q5m_76"
tabindex="0"><span class="button-text ">Subscribe</span></button>
</div>
<div id="error-container"></div>
</form>POST /api/v1/free?nojs=true
<form class="form _form_11q5m_6" action="/api/v1/free?nojs=true" method="post" novalidate=""><input type="hidden" name="first_url" value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="first_referrer"><input
type="hidden" name="current_url" value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="current_referrer"><input type="hidden" name="first_session_url"
value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="first_session_referrer"><input type="hidden" name="referral_code"><input type="hidden" name="source" value="post-end-cta"><input type="hidden"
name="referring_pub_id"><input type="hidden" name="additional_referring_pub_ids">
<div class="_sideBySideWrap_11q5m_10">
<div class="_emailInputWrapper_11q5m_57"><input class="pencraft _emailInput_11q5m_23" type="email" name="email" placeholder="Type your email..."></div><button tabindex="0" type="submit"
class="button rightButton primary subscribe-btn _button_11q5m_76"><span class="button-text ">Subscribe</span></button>
</div>
<div id="error-container"></div>
</form><form class="_form_1lzjp_6">
<div style="--scale: 32px;"
class="pencraft pc-display-flex pc-width-32 pc-height-32 pc-justifyContent-center pc-alignItems-center pc-position-relative _flexAuto_1tdk8_341 pc-reset _bg-secondary_1tdk8_212 _outline-detail_1tdk8_67 pc-borderRadius-full _overflow-hidden_1tdk8_351 _sizing-border-box_1tdk8_385 _container_1yh57_1">
<div style="--scale: 32px;" title="User"
class="pencraft pc-display-flex pc-width-32 pc-height-32 pc-justifyContent-center pc-alignItems-center pc-position-relative _flexAuto_1tdk8_341 pc-reset _bg-secondary_1tdk8_212 _outline-detail_1tdk8_67 pc-borderRadius-full _overflow-hidden_1tdk8_351 _sizing-border-box_1tdk8_385 _container_1yh57_1">
<picture>
<source type="image/webp"
srcset="https://substackcdn.com/image/fetch/w_32,h_32,c_fill,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Favatars%2Fdefault-light.png 32w, https://substackcdn.com/image/fetch/w_64,h_64,c_fill,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Favatars%2Fdefault-light.png 64w, https://substackcdn.com/image/fetch/w_96,h_96,c_fill,f_webp,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Favatars%2Fdefault-light.png 96w"
sizes="32px"><img src="https://substackcdn.com/image/fetch/w_32,h_32,c_fill,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Favatars%2Fdefault-light.png" sizes="32px" alt=""
srcset="https://substackcdn.com/image/fetch/w_32,h_32,c_fill,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Favatars%2Fdefault-light.png 32w, https://substackcdn.com/image/fetch/w_64,h_64,c_fill,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Favatars%2Fdefault-light.png 64w, https://substackcdn.com/image/fetch/w_96,h_96,c_fill,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack.com%2Fimg%2Favatars%2Fdefault-light.png 96w"
width="32" height="32" draggable="false" class="_img_16u6n_1 pencraft pc-reset">
</picture>
</div>
</div>
<div class="pencraft pc-display-flex pc-flexDirection-column pc-gap-8 _flexGrow_1tdk8_338 pc-reset"><textarea name="body" placeholder="Write a comment..." rows="4"
class="pencraft _input_1lzjp_1 _autogrowing_1ve2b_17 _textarea_1ve2b_5 _inputText_1ve2b_25" style="height: 98px;"></textarea>
<div style="height: 0px; transition: height 250ms var(--animation-smoothing), opacity 250ms var(--animation-smoothing); display: block; flex-direction: column; opacity: 0;">
<div style="padding-top: 0.05px; padding-bottom: 0.05px; display: block; flex: 0 0 auto; flex-direction: column; transition: transform 250ms var(--animation-smoothing);"></div>
</div>
</div>
</form>POST /api/v1/free?nojs=true
<form action="/api/v1/free?nojs=true" method="post" class="form _form_11q5m_6" novalidate=""><input type="hidden" name="first_url" value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="first_referrer"
value=""><input type="hidden" name="current_url" value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="current_referrer"><input type="hidden" name="first_session_url"
value="https://www.eatingpolicy.com/p/project-vs-product-funding"><input type="hidden" name="first_session_referrer" value=""><input type="hidden" name="referral_code"><input type="hidden" name="source" value="subscribe_footer"><input
type="hidden" name="referring_pub_id"><input type="hidden" name="additional_referring_pub_ids">
<div class="_sideBySideWrap_11q5m_10">
<div class="_emailInputWrapper_11q5m_57"><input type="email" name="email" placeholder="Type your email..." class="pencraft _emailInput_11q5m_23 _emailInputOnAccentBackground_11q5m_49"></div><button type="submit"
class="button rightButton primary subscribe-btn _button_11q5m_76 _buttonOnAccentBackground_11q5m_89" tabindex="0"><span class="button-text ">Subscribe</span></button>
</div>
<div id="error-container"></div>
</form>POST /api/v1/user/profile
<form class="form " action="/api/v1/user/profile" method="post" novalidate=""><label for="name">Name (Required)</label><input autofocus="true" type="text" class="profile-name" placeholder="Type your name..." name="name" id="name"><label
for="handle">Handle</label><input type="text" class="profile-name" placeholder="Type your handle..." name="handle" id="handle"><label for="bio">Bio</label><textarea class="profile-bio" placeholder="Say something about yourself..." name="bio"
id="bio"></textarea><label for="email">Email (Required)</label><input type="email" class="profile-email" placeholder="Your email…" name="email"><label class="pencraft pc-display-flex pc-gap-8 pc-reset _tosCheckbox_653qn_1">
<div class="pencraft">
<div
class="pencraft pc-display-flex pc-justifyContent-center pc-alignItems-center pc-boxShadow-xs pc-position-relative pc-reset _border-detail_1tdk8_25 pc-borderRadius-xs _sizing-border-box_1tdk8_385 pencraft _container_jtp38_1 _sm_jtp38_18 _enabled_jtp38_43 _checked_jtp38_56">
<svg xmlns="http://www.w3.org/2000/svg" width="14" height="14" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="3.5" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-check">
<path d="M20 6 9 17l-5-5"></path>
</svg><input checked="" class="pencraft" type="checkbox" role="checkbox" name="free_signup" data-testid="free_signup" aria-label="free_signup"></div>
</div>
<div class="pencraft pc-display-flex pc-flexDirection-column _flexGrow_1tdk8_338 pc-reset"><span class="pencraft pc-reset _line-height-20_h3mln_80 _font-text_h3mln_106 _size-15_h3mln_47 _weight-regular_h3mln_142 _reset_h3mln_1">Subscribe to the
newsletter</span></div>
</label><input type="hidden" name="confirmation_redirect_pathname" value="/p/project-vs-product-funding"><input type="hidden" name="photo_url"><input type="hidden" name="user_id"><input type="hidden" name="needs_photo" value="false"><input
type="hidden" name="token">
<div id="error-container"></div>
<p class="left hidden">undefined subscriptions will be displayed on your profile (<a>edit</a>)</p>
<div class="modal-ctas">
<p class="skip hidden"><a class="small">Skip for now</a></p><button tabindex="0" type="submit" class="button primary">Save & Post Comment</button>
</div>
</form>Text Content
EATING POLICY SubscribeSign in SHARE THIS POST Eating Policy Project vs Product Funding Copy link Facebook Email Notes More DISCOVER MORE FROM EATING POLICY In business, culture eats strategy. In government, culture eats policy. Here we'll talk about the problems of state capacity (government's ability to achieve its policy goals) and how to fix them. From the author of Recoding America. Over 6,000 subscribers Subscribe Continue reading Sign in PROJECT VS PRODUCT FUNDING MODERNIZATION SHOULDN'T EVEN REALLY BE A THING AT ALL. Jennifer Pahlka Jun 03, 2024 79 SHARE THIS POST Eating Policy Project vs Product Funding Copy link Facebook Email Notes More 16 6 Share Photo credit: Scott Robinson, CC BY 2.0 DEED A few months ago, I made a slide deck about the differences between funding technology as projects and funding them as products1. Every time I’ve shown it since then, people have asked me for a copy of the slides, so I thought I’d share them here in case they can be helpful more broadly. I also wrote up the narrative that goes along with them and included it in my Congressional testimony in January, so I’ve adapted that below. A link to the slides themselves is at the end. As with most of what I talk about, this is nominally about technology in government but applies far beyond tech. We need to acquire ongoing capabilities, not static things, in lots of parts of government. *** We procure and fund software as if it were static, and thus make it both worse and more expensive. This is best illustrated through a series of graphs, each one entirely fictional but representative of two fundamentally different approaches to funding software. Subscribe Government typically follows a “project” model. The following graph shows the number of staff who work on an IT project at its outset, as requirements are being developed, a request for proposal written, bids from contractors sourced and evaluated, and a winner chosen. The contractor, once hired, brings a team to develop the software based on the RFP, and the staffing levels (counting both internal and contracting staff) shoot up. There is a development period, followed by a short period of “user acceptance testing,” and then the project falls into “operations and maintenance,” (or O&M), which is generally a different color of money than the development funds. (This is a huge problem worthy of a separate discussion, but see here for a start.) Contrast this with a typical “product” model, in which, instead of a requirements gathering phase up front, a small team, often but not always internal to government, conducts what are called discovery sprints to better understand the problems the software is supposed to address. If some parts of the proposed solution are riskier than others (for instance, it’s not clear whether a data integration will work well), they find ways to test those problems first, before an entire software solution has been built. They may develop prototypes to help question their assumptions, and they engage with users from the beginning. Product teams almost always leverage contractors, but the contractors are there to complement a core internal team which holds the product vision and provides clear direction to vendors. Staff is added slowly over time as the team learns what they need, but doesn’t dramatically ramp down once a first or even second version is shipped. As my colleague Dave Guarino quips, “Google didn’t lay everyone off after they put up search.” Indeed, they invested more. At this timescale, there seems to be an obvious reason to prefer the project model: the minimal ongoing expense. This is what appropriators and oversight staff in Congress and elsewhere seem to be looking for as a sign of success. But as anyone following government technology appropriations knows, this is not the right timescale to look at. What happens next on the project line is one or more of the following scenarios: the software doesn’t work well for its users, and funds are sought to fix its defects; it quickly becomes outdated, either by changes in the technical environment, the policy environment, or other external factors, and funds are sought for modernization; or new needs have emerged that the existing software doesn’t address…and funds are sought to meet those needs. Thus, the actual project model line looks more like this in the medium term: And then in the longer term, as modernizations fail, needs escalate, and even more money is allocated, like this: Here is where the slow and steady product line starts to look a lot more attractive, on a purely cost basis. But cost is far from the only reason to prefer it. Having a consistent team over time may look like an unwanted ongoing expense, if we assume that development work is at some point “done,” but that is not the case. (“Software is never done” was one of the precepts of the Software Acquisition Practices report I contributed to for the Defense Innovation Board). If software isn’t updated, it rots in a variety of ways. O&M should be relabeled ROT. (Someone please backronym that for us.)2 Leave a comment The product model is not only less expensive in the long run, it results in working software that doesn’t need “modernization” of the kind you’ve become used to hearing about because it’s constantly being updated and improved. To extend Dave’s quip, you don’t hear about Google pausing search for a modernization. Google Search first came out in 1998, and I doubt its code base today bears much relation to what existed then. But Search is a product, not a project. It never went into O&M. It changed daily, not every other decade. If you’ve worked in government you’ve seen Whong’s Law in action: “Every government agency, everywhere is working on a “new system”; It will solve *all* of their data problems and will be ready to use in 18-24 months.” The joke, of course, is that it will always be ready in 18-24 months, and in the meantime, because the new system will solve all problems, no improvements can be made. Have a need? Find a workaround for the time being…which turns into effectively forever. When I worked on unemployment insurance in California during the pandemic, the team had been working on a procurement for a new system for eleven years. The request for proposal hadn’t even gone out for bid yet, so the start of development was at least a year away (probably a lot more), but the team had been in this "find a workaround” state, in which problems get kicked down the road (or more accurately, kicked into the requirements of a mega-project that will take another decade to build) since the last modernization shipped. Of course the UI system in California couldn’t scale to meet demand. It had been rotting for decades. In contrast, New Jersey’s unemployment insurance team was making improvements every few days throughout and beyond the pandemic. The Department of Labor just crowed about that state’s successful new system, a success built on “a continuous approach to IT modernization over an all-or-nothing strategy.” Dave Cole, New Jersey’s Chief Innovation Officer, said at the press conference: “Far too often, other states, large and small, have spent hundreds of millions of dollars to do one monolithic overhaul of their UI technology and applications, only for the resulting experience to remain just as confusing, just as frustrating, and just as demoralizing for claimants and state UI staff.” It’s great to see a state escape that trap. More eyes should be on New Jersey. Products also don’t wait to meet their users until they’re in a “testing phase” at the end, when some of the engineers have already been moved to other projects and the project’s budget is almost entirely spent. Understanding users — not documenting requirements, as the two are different — is what that tiny initial team is doing, and what the growing team does along the way. The biggest difference between the project and product models is that the steady investment over time delivers effective service to the American people. Periodic investment in “projects” is how we get backlogs and confused and frustrated constituents. Share A summary of the differences in these models is below3: As much as it's tempting to hold agencies accountable for their addiction to the project model, this is not something they can fix on their own. Congress would need to enable ongoing funding streams (in addition to procurement changes previously discussed) in order to see agencies develop in the product model. Congress should work with OMB and agencies to change the laws, regulations, processes, and practices that impede agencies from operating in the product model. *** That last sentence is a bit of a doozy, I admit. It’s the kind of thing one says in the written version of Congressional testimony, as if it were something that one could just do, or that anyone in Congress actually wanted to do. But it’s our jobs to make it a priority for them, and as we do, we need to figure out tactically how this will really work. I hope you’ll contribute to that plan. In the meantime, here’s a link to the slides. Feel free to use them with credit, but let me know if you do, and in what context, and how they are received. Subscribe 1 My best shorthand for the difference here is that project management is the art of getting things done. Product management is the art of deciding what to do. (Thank you to Bennett Hillenbrand for that line.) (See Chapter 10 of Recoding America for more.) But obviously, there’s a lot more to it. 2 Update: 20 mins in and we already have a winner here. April Harding suggests ROT could stand for Recurring Obligations for Technology. I love it. 3 In the chart (which is an image from the slides because Substack doesn’t seem to do columns), I list Byrne’s Law under the Product Model side. That’s from my book Recoding America. This is Mike Byrne’s assertion that most government tech projects could cost 10 percent of what they do and still provide 85 percent of the functionality. This is not quite the same as the concept of a minimum viable product (MVP), which would be far less than 85 percent of the functionality, but in the same general direction. SUBSCRIBE TO EATING POLICY By Jennifer Pahlka · Hundreds of paid subscribers In business, culture eats strategy. In government, culture eats policy. Here we'll talk about the problems of state capacity (government's ability to achieve its policy goals) and how to fix them. From the author of Recoding America. Subscribe 79 Likes · 6 Restacks 79 SHARE THIS POST Eating Policy Project vs Product Funding Copy link Facebook Email Notes More 16 6 Share DISCUSSION ABOUT THIS POST Comments Restacks Kevin Sutherland 3 Jun Liked by Jennifer Pahlka I love this post! As someone who has been either planning and delivering large system modernization projects for over 20 years, it really resonates! Unfortunately, my experience is states are not equipped / able to shift to a product funding model for many of the reasons so beautifully articulated in Recoding America. To name a few: 1. State organizations are primarily functionally organized. I.e., IT is a separate hierarchical structure from the business areas. 2. The current technology is like an archeological dig site with layers upon layers of older, highly coupled, poorly understood technology making it challenging to even identify a "product" 3. The accountability paradox is deeply ingrained in the culture and behaviors of staff. In my experience, the desire to move to a product model will fall short unless these issues can be resolved. Interested in thoughts from the community on how to address. Expand full comment Like (4) Reply Share 2 replies by Jennifer Pahlka and others Dave Rooney 3 Jun Liked by Jennifer Pahlka Great post! I worked on a team from 1992-1998 in the Canadian federal government that used this model (fund the team, not projects). There were a few capital investments over that time on new server hardware, for example, but the ongoing operating costs were really just the costs of the team. We did *great* work, at least according to the people who used the systems we produced. We were responsive to their needs and could pivot quickly when there was a change in the business. I wish more organizations today we like this one was 25-30 years ago! Expand full comment Like (3) Reply Share 2 replies by Jennifer Pahlka and others 14 more comments... Top Latest Discussions Bringing Elon to a knife fight Wishing for a more orderly disruption may misunderstand the nature of government reform Dec 13 • Jennifer Pahlka 244 SHARE THIS POST Eating Policy Bringing Elon to a knife fight Copy link Facebook Email Notes More 68 Stop telling constituents they're wrong But start making sure your policies don't fall prey to the cascade of rigidity Nov 22 • Jennifer Pahlka 195 SHARE THIS POST Eating Policy Stop telling constituents they're wrong Copy link Facebook Email Notes More 82 The DOGE strategy is a cop-out Elon and Vivek's workforce plans would backfire terribly. There's a welcome alternative. Dec 2 • Jennifer Pahlka 102 SHARE THIS POST Eating Policy The DOGE strategy is a cop-out Copy link Facebook Email Notes More 27 See all Ready for more? Subscribe © 2024 Jennifer Pahlka Privacy ∙ Terms ∙ Collection notice Start WritingGet the app Substack is the home for great culture SHARE Copy link Facebook Email Notes More CREATE YOUR PROFILE Name (Required)HandleBioEmail (Required) Subscribe to the newsletter undefined subscriptions will be displayed on your profile (edit) Skip for now Save & Post Comment ONLY PAID SUBSCRIBERS CAN COMMENT ON THIS POST Subscribe Already a paid subscriber? Sign in CHECK YOUR EMAIL For your security, we need to re-authenticate you. Click the link we sent to , or click here to sign in. This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts