Product Prioritisation When Software Development Costs Approach Zero

X postCalvin GrunewaldDiscussion

Calvin Grunewald questions conventional growth backlog prioritisation models and opens a discussion on how teams should decide what to build once development costs drop significantly.

Key points

  1. At previous companies including Stripe and Facebook, product teams prioritised post-PMF growth backlogs using t-shirt sizing based on estimated cost and expected impact.
  2. Grunewald raises the core question of what prioritization framework replaces this approach when the cost of building software drops to near zero.
  3. He suggests that human attention becomes the primary scarce resource, while agent-related token and hardware expenses remain predictable relative to live infrastructure operations.
  4. Growth backlogs can also accommodate simplification, feature removal, or non-traditional metrics like integrity via capacity budgeting.

Why it matters

As AI tools and agents compress implementation timelines and costs, engineering effort stops being the main constraint dictating roadmap decisions.

Analysis

The standard cost-versus-impact matrix breaks down when the cost to build becomes negligible. Grunewald notes that while growth teams historically focused on immediate build costs rather than technical debt or maintenance, future prioritisation must shift focus towards how impact is defined and manage the true scarce constraint: human attention.

Original post

Calvin Grunewald

@CalvinGrunewald · 6 October 2026

At previous companies (Stripe, Facebook, etc), I used the below prioritization framework to figure out what to work-on for growth (past PMF) products. Teams would brainstorm, look at customer feedback, look at data, and then generate a list of ideas (the backlog). Then, t.co/GDCHmEuvRp

46 likes12 replies96 bookmarks10k views

View on X
More posts in the thread (10)
  1. @pucknorris From a moat perspective, that’s pretty good. But that could also just be boiled into impact.
  2. @czexan_cowboy When you apply this framework, you are free to define cost as you want. Most of the time in growth products, the cost is literally building. Most growth teams manage tech debt correctly as part of a separate process.
  3. @AnichoBuilds Haha, yes! I definitely think that how you define Impact changes.
  4. @czexan_cowboy So many thoughts. A few below: 1. Growth backlogs can model progress towards other goals than just your typical product KPIs. IE, if integrity is an issue, you can model work against that in a way that goes into the backlog (capacity budgeting is the simplest way). 2. Product
  5. @ohavbenyanai @czexan_cowboy Hopefully it scales more with product usage rather than development costs.
  6. @wotkha Removing/simplifying things are often great experiments to put on a backlog. They can all be represented with this framework.
  7. @ohavbenyanai @czexan_cowboy Yeah, it certainly will cost more to scale up your use of agents (both hardware and tokens). But these are still fixed costs relative to operating the infra for your actual service. If you've got PMF and are working on growth, there is some financial calculation you can do to
  8. @MrShellyB This is the sort of data/research that informs the backlog and impact scores.
  9. @VocxAI_ Yes!
  10. @VocxAI_ Human Attention.
Selected replies (5)
  • @czexan_cowboy @CalvinGrunewald Thing about the costs as "costs of building" is the myopic mistake. - cost of builduing - cost of maintanence - cost of future iterations and composability (opportunity costs of the future iterations you won't be able to build on top)
  • @AnichoBuilds @CalvinGrunewald Just shift the ambition. What was high cost high impact is low cost small improvement now 😂. Time to think grander.
  • @czexan_cowboy @CalvinGrunewald Hmm, that explains why in my experience the growth teams are hated by the platform/core teams for their sloppiness and carelessness about the future. What's the argument to not try to account for the "full costs" (as good as we can define them). Maybe besides trying to hit the
  • @wotkha @CalvinGrunewald most new features are not used as often as planned. why not use agents to remove features instead of only adding up... and not sure if a matrix is valid tool to prioritize anything.
  • @pucknorris @CalvinGrunewald Isn’t it inverted? High cost maybe high complexity (more defensible) yet high impact

Mentioned links

Summary generated by AI (Gemini 3.8 Flash, 8 October 2026). It may contain errors – the original source is authoritative.

Related entries

Similar in content, found by the AI search.

  • Video

    Video:AI Native Dev

    The Reinvention of the Dev Team in the Agentic AI Era

    At AI Native DevCon, Hannah Foxwell examines how agentic software engineering disrupts traditional team dynamics, organizational ratios, and engineering bottlenecks. As development velocity explodes, the operational friction moves away from writing code toward product validation, continuous safety, and sustainable on-call operations.

    AI & LLMs· Talk

  • X post:Mario Zechner

    Pragmatic Leverage in the AI Software Factory

    Mario Zechner highlights an analysis by Dex Horthy on achieving true leverage with AI in software engineering. Horthy argues that accelerating code generation alone yields minimal overall gains, as writing code historically represents only 25 to 50 percent of delivery time. Substantial acceleration occurs only when AI aids planning and alignment.

    913bookmarks98.2kviews

    AI & LLMs· Opinion

  • Link:Chris Ashby

    Chris Ashby: Product Studio for AI-Assisted Builders

    Chris Ashby offers the 'Product Studio', a mentorship programme designed for domain experts building applications with AI. Based on his four-stage 'Product OS' framework, it aims to guide half-built projects towards launched, revenue-generating products.

    AI & LLMs· Resource

  • Article:Nate

    Agent Maintenance: Why Pruning AI Systems Matters More Than Building Them

    Nate argues that maintaining AI agents will soon be a more critical skill than creating them. Agents continue to generate output long after becoming inaccurate. Citing Vercel's decision to delete 80% of its sales agent's tools to improve results, he outlines how stripping away bloat and maintaining structural harnesses keeps systems reliable.

    AI & LLMs· Opinion

  • Video

    Video:Greg Isenberg

    Managing Teams of AI Agents: Ryan Carson on Cloud-First Development

    In an interview with Greg Isenberg, Untangle founder and former Treehouse CEO Ryan Carson outlines how knowledge workers are evolving into managers of AI agents. He shares why cloud-hosted VMs replace local environments, how he ships 22 to 40 PRs daily, and the operational automations required to monitor agent behaviour and secure production keys.

    AI & LLMs· Talk

  • Link:Fredrik Falk

    Anthropic Splits Chat and Agent Billing: The True Cost of AI Agents

    Anthropic has updated its subscription model to separate interactive chat from Agent SDK consumption. Fredrik Falk examines the economics behind the move: while per-token costs continue to drop, the multi-step context re-processing required by autonomous agents is driving enterprise inference budgets rapidly upward.

    AI & LLMs· Opinion

Back to the knowledge base

Let's talk about your project

Get in touch

Locations

  • Mattersburg
    Johann Nepomuk Bergerstraße 7/2/14
    7210 Mattersburg, Austria
  • Vienna
    Ungargasse 64-66/3/404
    1030 Wien, Austria

Parts of this content were created with the assistance of AI.