# Dacard.ai > Darren Card: product and technology leader, builder and operator, in > Vancouver, with twenty years in B2B SaaS. The claim: building software got > cheap, so the scarce work moved to judgment. Deciding what is worth > building, and reading whether what shipped actually landed. He works with > three kinds of companies: software companies (a full-time or fractional > product and technology leader), businesses handing operations work to AI > (ready-made on Claude for Small Business, or built around the operation), > and digital agencies turning their best work into a product (the agency > keeps the craft and the client; he leads the product and the software). Terms with a fixed meaning on this site: "landed" means shipped work that measurably connected; "stalled" means shipped work that did not; "watch" means too early to call. Agents read, draft, and check. A person makes every call. Throughline is the working prototype that runs the method: it wires into the tools a team already runs, and the public read on the site runs without asking the company for anything. ## The pages - [Software companies](https://dacard.ai/software): A product and technology leader, full-time or fractional - [Digital agencies](https://dacard.ai/agencies): Turn your best work into a product - [Business operations](https://dacard.ai/operations): AI that runs the ops work, you approve - [The person](https://dacard.ai/person): The record and the background - [The point of view](https://dacard.ai/pov): What I think and why, and the thesis - [The prototype](https://dacard.ai/prototype): Throughline, agentic operations running - [The paper trail](https://dacard.ai/paper-trail): What I keep running into ## The notes, in full ### 13. Four numbers, three of them proxies Published: September 2026. Reading time: 4 min. Source: https://dacard.ai/paper-trail/four-numbers-three-of-them-proxies A slide from a credible source puts four AI outcomes side by side. Three of them measure time saved, which is the input. The fourth is the only one a CFO can bank. ICONIQ published a slide this year on how AI is landing inside G and A functions at their portfolio companies. It is a good slide. It is specific, it names sequences rather than tools, and its footer is more careful than most: illustrative examples observed at select portfolio companies, and not intended to represent benchmarks or survey findings. I would quote it in a room. Across the top it carries four outcomes. Annual cost savings of two to four million dollars. Forty to sixty per cent faster time-to-hire. Forty-five to eighty per cent time saved in knowledge retrieval and analytics. Thirty to eighty per cent time saved on the finance close and reporting. Read those again as measurements rather than as results. One is money. The other three are time. Faster time-to-hire does not say whether the people hired were better, or stayed. Time saved in retrieval does not say whether anyone made a different decision with what they found. Time saved on the close does not say whether the close was more accurate, or whether the quarter it reported was read correctly. Time saved is what the work costs. It is not what the work returned. This is the ordinary shape of a proxy metric. A proxy is a number that moves with the thing you care about, chosen because it is easier to observe. It earns its place right up until the moment it comes loose, and then it keeps reporting while the thing underneath stops moving. The failure is quiet, because the number still goes up. Three of these four are the same proxy in different departments. That is worth noticing, because it tells you what the market currently finds easy to measure, and what it has not started measuring at all. The one that is different is the two to four million. That is a number a finance team can put in a plan and check against an actual. It has a denominator and a period and an owner. It is the only one of the four I would build a case on, and I notice it is the one the slide marks as most impactful. There is a second number further down the same page that I think is more useful than any of the four, and it is buried in a quote rather than set in the outcome row. A CFO at a five-hundred-million-dollar ARR company says their token spend went from near zero to roughly five to ten per cent of payroll, and that they pulled it out of the future headcount plan. That sentence does something the percentages cannot. It gives AI spend a denominator that already exists in every company, and a budget line it can be taken from. Most AI ROI numbers in circulation are numerators with nothing underneath them, which is why a finance team cannot act on them even when they are true. The same CFO opens with a line worth holding onto: the hard part is finding the value, not controlling the cost. Once a use case is valuable and expensive, the cost work is known. Mid-tier model defaults, caching, tiering by what the task is worth. Their spend came down while usage climbed. None of that is the hard part. The hard part is knowing which use case was worth having in the first place, and then whether it did what you thought it did after it shipped. Neither of those is a cost question, and neither is answered by a percentage of time saved. I am not saying the slide is wrong. The practices on it are the right practices, in what looks to me like the right order: standardise the manual workflow, put the person who owns the work in the builder seat, then share what they built as governed infrastructure. I would run an engagement in that order. I am saying that if you lift the outcome row into your own board deck, you will be reporting three numbers that measure effort and calling them results. Somebody at that table will eventually ask what changed for a customer, and the row will not have an answer. The fix is not more measurement. It is picking the one number per bet that would look bad if the bet failed, agreeing it before the work starts, and reading it against the proxy afterwards. When the proxy climbs and that number does not, you have learned something. That gap is the finding. > Time saved is what the work costs. It is not what the work returned. ### 12. The view from the ProdOps pit wall Published: July 2026. Reading time: 3 min. Source: https://dacard.ai/paper-trail/the-view-from-the-pit-wall Agents move at racing speed. The pit wall is the one surface that reads the whole operation, and where a person still makes the call. This began as a companion to Mike Gilpin's piece on the context layer: the governed store of what is true, who owns it, and what happens when it changes. His case is that the context layer is a project before it is a product, and that the project is mostly human. He is right, and it is the part vendor demos skip. But a foundation is for something. Here is what it is for. In 2015 you could service and keep a personal-use car on track from a laptop. The whole car's telemetry fit on one screen, and one person could read it by hand. The work moved slowly enough to watch. In 2026 it does not move at that speed anymore. Agents build in an afternoon what used to take a quarter, and the moment building got cheap, production, the thing that used to gate everything, stopped being the constraint. Speed became a habit anyone installs overnight. Once everyone has it, speed stops being the edge. What stays scarce is the part speed cannot supply: deciding what is worth building, and knowing whether it works. So you do what a Formula 1 racing team does when the car outpaces any human driving it blind. You build a pit wall. The pit wall is one live surface across the whole operation: the strategy, the design, the engineering pipeline, and the go-to-market stack, read together. A racing team does not watch telemetry to admire it. They watch it to decide, mid-race, where the next lap of effort goes. The wall reads the whole thing and writes the next move, so a person can pour more into what is landing and pull back from what is not while the work is still in motion. Agents sit at that wall now, some for the strategy read and others for the operations read, each watching a bank of screens no person could hold at once. But the wall does not make the call. One human does. The machine multiplied around the person; the person is still the one thing that did not. That is the whole picture, and it fits in two frames. One screen and one reader, then a wall of screens and the same reader, with agents alongside. The count of humans making the call did not change. What multiplied was the machine. When the platform can ship almost anything, strategy is deciding what is worth shipping, and operations is making each ship teach the next. Those are not two departments trading memos across a table. They are one motion, read off one surface. Strategy sets the direction; operations read the result. At racing speed, they are the same lap. The pit wall is the one place they meet, which is why the role that owns it is one role, not two. Instrument all of this and you can measure everything, which is its own trap. The number that matters is not how much you shipped, because shipping got cheap for everyone. It is whether what you shipped moved something real. Did it land? Shipping is the baseline now. Landing is the read. A team that ships twice as much and cannot say whether any of it mattered is just faster at guessing, and the pit wall exists to make that answer visible before the next bet. A pit wall is only as good as the data feeding it. Instrument the whole operation on a foundation that has no owner, no audit, and no way to ripple a change to everywhere it touches, and you have not built judgment. You have built a faster way to double down on the wrong thing. That is Mike's point, reached from the other side. He is looking at the foundation and saying it is human work that takes a quarter. I am looking at what stands on top of it and saying the same thing: the governance is not housekeeping. It is the precondition for the judgment. The context layer is a project before it is a product. The pit wall is what the project is for. And the job at the wall, the one thing that did not get cheap, is the call. First published on LinkedIn on 23 July 2026, as a companion to Mike Gilpin's piece on the context layer. > The machine multiplied around the person; the person is still the one thing that did not. ### 11. Your compression matrix is not your team Published: August 2026. Reading time: 3 min. Source: https://dacard.ai/paper-trail/your-compression-matrix-is-not-your-team Compression has a domain shape. Run the map per domain and the limits stop landing in the same place. Chuck Ros published a piece last week making the case that we measure AI's impact at the wrong altitude. Jobs are portfolios of tasks, AI compresses each task differently, and occupation-level claims like "engineers are 30% more productive" average away the detail leaders need. He is right, and I want to push the model one level further. A generic compression matrix treats knowledge work as one landscape. Compression has a domain shape. Run the same exercise separately for the product development lifecycle and for go-to-market and the two maps disagree, in ways that change how you staff and where the next limit lands. So I ran it. The bands below are directional estimates, drawn from the published research and calibrated against two years of shipping AI-native product. They describe the industry, and they do not describe your team. That distinction is the whole point. Read the two halves against each other and notice where the green sits. In the lifecycle, compression concentrates in the production middle: code, tests, documentation, first-draft specs. In go-to-market it concentrates at the top of the funnel: account research and content volume. The compressible work in both domains is the work whose output was already text, code, or structured data. Then look at where the green stops. First finding: the constraint lands in a different place per domain. The cleanest published version is the code result. In an NBER study of AI coding tools, developers using agents produced several times more code and 65% more pull requests, and releases rose only 20%, because delivery stopped being constrained by writing and started being constrained by review, integration, and approvals. Compress go-to-market and the constraint lands somewhere else entirely: on positioning, pricing, and the conversations that close. Same mechanism, different choke point, different owners in the room for the redesign. Second finding: go-to-market compresses more and yields less. More of its volume work automates aggressively, but its human-advantage zone is relational: trust and negotiation. Review capacity grows when you redesign the process; trust grows at the speed of relationships. So compressed lifecycle time can convert to throughput, while compressed go-to-market time mostly buys volume that piles up against a relational limit. Microsoft's field experiment across thousands of knowledge workers found the same asymmetry: email hours fell by around a third for regular users, and meeting time barely moved. Individual work compresses faster than collaborative work. Third finding: both maps end at the same cell. Ship or do not ship. Close or do not close. Zero compression, full accountability, one owner. When one task gets dramatically faster, another task becomes the limit. Every task upstream can compress, and the operating model still terminates in a call a person makes and answers for. If you are redesigning roles around AI, start at that cell and work backwards. Used correctly, a map like this is a directional instrument. Multiply band by exposure: 80% compression on a task worth 2% of the week is a rounding error, and a 40% band on a task that eats a third of it is the roadmap. Watch the constraint, not the compression: freed hours mean nothing if review, pricing, or the sales calendar cannot absorb them. And score what landed: more code, more content, and more pipeline are production metrics, and the number that matters is whether more of what shipped landed. That is the limit of any matrix, including the two in this note. Estimated bands say what is generically compressible across an industry. They cannot say what your team's evidence shows, or where your constraint sits this quarter. The teams that get this right will read their own signals, task by task. The rest will keep quoting a poster. Sources and credit: the code result is the NBER working paper "Writing Code vs. Shipping Code" (Demirer, Musolff, Yang); the email and meetings result is Microsoft's randomised field experiment with M365 Copilot across dozens of firms. The bands are my estimates, informed by that research, and this note exists because Chuck Ros's "We're Measuring the Wrong Thing" made the altitude point well enough to build on. > When one task gets dramatically faster, another task becomes the limit. ### 10. Agents broke the product org chart Published: July 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/agents-broke-the-product-org-chart Production got cheap. The chart we built around it stopped showing who is building the value. The org chart is a theory of where value comes from. We drew the current one when building was the expensive part: engineers built, PMs decided what to build, designers shaped it. The people who could make the thing sat at the centre. Agents took the hard part away. One person with good tools can build in days what a team spent a quarter on. I have done it, and I have watched others do it. A chart organised around who can build stops describing much. What is scarce now is judgment, in two forms: deciding what is worth building, and knowing whether what shipped landed. Both were always in the job. Neither was the constraint, so neither showed up in the boxes. The chart also cannot show that part of the team is no longer human. Agents do the read, the draft, and the check. What stays human is the call: one decision, one owner. That gives you a better unit of organisation than the function: the decision. Which segment to serve. What the pricing tier is. Whether to pull the launch. Each one carries exactly one name. Run that list for a quarter and you will learn more about your org than the chart ever told you. The people who carry over are the ones with taste, and taste is spread across every function. An engineer who always had a view on what was worth building is worth more now. A PM who ran process is exposed. So is a designer who shipped pixels without a point of view. The line runs through the functions, not between them. A reorg will not fix this, because the boxes were never the problem. Write down the decisions your org makes. Put one owner on each. Note what was measured and what was still a bet, and go back a quarter later to see which ones landed. The people you need are already in your org. The chart is not pointing at them. > The line runs through the functions, not between them. ### 09. You cannot ship AI you cannot afford Published: July 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/cost-is-the-number-nobody-instruments Unit economics are a build decision. Almost nobody makes it on purpose. Most teams I talk to can tell you what their AI product does. Fewer can tell me what one use of it costs to run. That gap is where AI products become too expensive to sell, and the team finds out from the bill. Cost is a build decision, not a finance one. Which model you pick. How much text you send it per call. How many calls per task. Whether a person reviews the output. Those four choices set what one use costs, and all four get made at the keyboard. The failure looks like this: the product works, adoption climbs, and gross margin slides while the room assumes AI is making things efficient. Model spend is a cost of goods sold, the line that sits against revenue. Park it in operating expenses and the margin looks better than it is. The version that works puts a price on each unit of work the system does: one answer, one document processed, one agent run. A monthly total tells you nothing you can act on. A per-action price you can check while you build, the same way you check speed or accuracy. Two levers move it more than model choice. The first is how much text you send with each call, where most of the waste and most of the quality both sit. The second is who does the checking: a rule costs close to nothing, a model costs cents, a person costs dollars and minutes. Route the cheapest reliable check first and save the person for calls that set a standard. None of this is glamorous, which is why it is an edge. Plenty of people can build an impressive AI feature. Far fewer build one that survives its own economics. Measure while you build, price per action, make the tradeoffs on purpose. > Park it in operating expenses and the margin looks better than it is. ### 08. Evals are the new code review Published: July 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/evaluation-is-the-new-code-review The gate that decides whether what you built is any good moved. Most teams have not moved with it. Code review exists because writing code is where mistakes enter. So we put a gate right there: another set of eyes on the diff before it ships. When agents write a growing share of the code, that gate stops catching what breaks. The failure lives in the behaviour: plausible and wrong, or right in the demo and wrong on the rare inputs. A person reading the diff line by line will not see it, because the diff looks fine. So the checkpoint moves, from "is this code correct" to "is this behaviour correct, across the inputs that matter." That is an eval: a set of cases run against the output, with a pass mark set in advance, and you do not ship past a failing gate. Who does the checking is a routing decision: cheapest reliable check first. Rules settle shape, format, and thresholds. A model handles what a rule cannot, cheap enough to run on every change. A person comes last, for calls that set a standard. A person cannot read ten thousand outputs, and a rule can. That is also the line agents do not cross. An agent can run the check and tell you six outputs look off. It does not set the threshold, and it does not decide a failing case is acceptable this once. The check is delegated. The standard is not. The tell that you have under-invested is confidence that comes from how it felt when someone tried it. That was the state of code quality before code review, and we did not accept it there. Deciding what to evaluate, and what threshold counts as good enough, is one of the most valuable calls a builder makes now. The eval suite is where your standard for quality stops being an opinion and becomes something the system enforces. > The check is delegated. The standard is not. ### 07. Velocity stopped meaning anything Published: July 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/velocity-stopped-meaning-anything When everyone ships fast, speed stops being the signal. What you chose to build is. Velocity was a useful metric because shipping was hard. If a team pushed features out quickly and reliably, that told you something real. Speed was a proxy for competence because speed was scarce. Agents made speed cheap. A small team, or one capable person, now ships at a rate that would have looked heroic two years ago. The proxy broke. Velocity metrics are sticky, though. A team that shipped twelve things nobody uses looks stronger on the page than a team that shipped three that moved the business. A high number can now mean the wrong things, produced quickly. Ask a different question. Shipping is the baseline; landing is the read. Every launch carries a status set from measured numbers: landed, watch, or stalled. Landed means the number you said would move, moved. Watch means the signal is thin. Stalled means it shipped and nothing happened. Stalled is where teams flinch, and it is the whole value of the exercise. A stalled launch nobody marks stays in the roadmap deck as a win, and the team keeps building on top of a thing that is not carrying weight. Marking it costs one uncomfortable sentence and saves a quarter. None of this means slow down. Anyone can be fast now. The teams worth copying are fast, pointed at the right things, and can show you which of the last ten launches landed. The second half of that sentence is the hard part, and it is the whole job. > Shipping is the baseline; landing is the read. ### 06. Hire for the PM job that exists now Published: July 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/hire-for-the-pm-job-that-exists-now The job stopped being coordination. Screen for the one who can still build. Most companies still hire product managers against a rubric built for a job that is going away. It rewards the person who runs the process: gathers requirements, aligns stakeholders, keeps a room of specialists pointed the same direction. Real work, when coordination was the constraint. Building got cheap. The work moved to judgment, which is two things: deciding what is worth building, and knowing whether what shipped landed. Neither one is coordination. And agents now do the read, the draft, and the check, which is most of what the coordinator carried between people. Hire against the old rubric and you are selecting for the part that just got automated. The gap shows in the interview. Ask a candidate to walk through a launch and notice who is in the story. If it is all "I aligned the teams and drove the roadmap," you have a coordinator. Then ask the question most candidates have never been asked: how did you know it landed? Screen for three things. A call they made when the answer was not obvious, and what would have changed their mind. A shipped thing they can mark landed, watch, or stalled from measured numbers. And what they hand to agents against what they refuse to hand over. The good answer to the third is specific: they delegate the read, the draft, and the check, and they keep the call. Look for someone who will get their hands in the work: write the spec, look at the output, say exactly what is wrong with it. That person is worth more than one who has only ever run the room, even when the room was bigger. There is a trap on the other side. Screen only for raw building speed and you get someone who ships beautifully and has no view on what deserves to ship. The person you want holds both halves: the judgment to pick the right thing and the hands to help make it real. Rare, and that is the point. Titles stopped predicting value here. The best candidate for this seat may have been called a founder, a design lead, or a staff engineer. You are not filling the old seat faster. You are hiring for the seat that exists now. > Titles stopped predicting value here. ### 05. Smiling exhaustion is a system bug Published: July 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/smiling-exhaustion-is-a-system-bug When one person covers what used to take five, burnout is not a mood. It is a design flaw. There is a particular look on people building at the edge of what agents make possible: lit up and worn out at the same time. The smile is real and so is the tiredness. The tiredness is a signal about the system, not a verdict on the person. Building software got cheap, so it takes fewer people to make a thing. The same change moved all of the work onto fewer shoulders. One person now holds what used to sit with five: the product calls, the build, the review, the economics, the customer contact. Each piece got easier. The sum got heavier, because there is nobody to hand any of it to. That is a property of the design, not of anyone's stamina. No single task is too hard; the load comes from the shape of the work. Rest does not fix a structural overload. The load refills the moment you are back. The fix is a design fix, and it has two parts. The first is routing. Agents can carry the read, the draft, and the check, and most people under this load have not handed it over, because they do not trust the material underneath. A fair concern and a solvable one. The call stays with the person: one decision, one owner. Your finite attention should go almost nowhere else. The second is a single surface. What tires people out is not the tasks, it is the reassembly: strategy in one place, design in another, the build in a third, go-to-market in a fourth, and a person stitching it together in their head every morning at a cost nobody counts. Put them on one live surface and knowing where things stand drops from an hour of reconstruction to a glance. The small team that builds like a large one only holds if you design it to be sustainable. Run it on one person absorbing load until something gives and you have the old operating model with the headcount removed. Smiling exhaustion is the warning light. Treat it as information about the design and it is fixable. > Smiling exhaustion is the warning light. ### 04. The one-person product org, from the inside Published: June 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/the-one-person-product-org What it is actually like to build the whole surface yourself, agents and all. The pitch for the one-person product org is seductive and mostly true. You hold the whole thing in your head, decide and build in the same motion, and ship without routing anything through a committee. When it works, it is the shortest line from idea to shipped I have ever worked on. What the pitch leaves out is what you become. You have to be right about what is worth building, direct the agents that build it, review what comes back, and catch your own bad ideas with nobody else in the room. The agents handle the read, the draft, and the check. They do not handle the call, and the calls are now the entire job. The part that surprised me is how much of the work is saying no to myself. I can build almost anything I think of, so the ceiling on what ships is set by the quality of what I choose to build. The discipline that used to come from the org has to come from the system I build around myself. The tight loop is the advantage and the risk. Idea to shipped can happen inside a day, and there is no natural friction to catch a mistake. On a team, other people are the friction, and the friction is irritating and it saves you. Alone, you build it on purpose: the test cases that gate a release, the cost checks, the pause to ask whether this is worth an afternoon. What made it workable for me was a pit wall. In racing, the pit wall is the crew that watches the whole race and tells the driver what to do next. So one live surface holds strategy, design, the build, and go-to-market, and I stand at it a few times a day deciding where the next lap of effort goes. Every launch on it carries a verdict from measured numbers, and the verdict is only as good as the numbers under it. So the true version of this is not "I do everything." It is "I own the calls, and I have routed or gated everything that is not a call." Get it right and you operate like a team of five with the coherence of one mind. Get it wrong and you are one person doing five jobs quickly and poorly. Which one you end up with is a design choice. > Get it right and you operate like a team of five with the coherence of one mind. ### 03. The model was never the constraint Published: June 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/the-model-was-never-the-constraint The constraint was never the model. It is knowing what is worth building and whether the output holds up. Every model release brings the same reaction: now we can finally build the thing. And every time, most of the teams I work with find the model was not what stopped them. The constraint sat somewhere else the whole time. The model is the production engine. It writes, it reasons, it acts. It does not decide what is worth producing, or settle whether what came out is any good. Those two calls set a product's quality, and both sit on the human side. You can watch it play out. A team gets a stronger model and ships more. The extra output is not better, it is more, because they pointed a faster engine at the same undecided backlog. Upgrade the engine, keep the gaps, and you get faster mediocrity. The other half is what the model reads. Give it a strong opinion and little to read, and it produces a confident answer built from a stale doc and a number nobody ever checked. If you cannot click from the claim to where it came from, you do not have an answer. You have a plausible sentence, and owning a call you cannot trace is guessing with extra steps. This changes what to invest in. Get sharper about what is worth doing, build the source of truth the work reads from, and build the checks that tell you whether you did it. Those compound across every model release. The frontier will not help if you cannot tell it what is worth building or check what it built. So the useful question when a new model lands is not "what can we build now." It is "were we blocked on the model at all." Almost always the answer is no, and no upgrade ships the two things that were: deciding what to build, and judging what came out. > Upgrade the engine, keep the gaps, and you get faster mediocrity. ### 02. Engineering is the only function you can see Published: May 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/engineering-is-the-only-function-you-can-see Eng has the metrics, so eng gets the credit. The judgment about what is worth building stays invisible. Engineering is the most measured function in most companies, and it is not close. Commits, deploys, cycle time, incident counts, DORA. You can see the work, so you can manage it, reward it, and settle disagreements about it with numbers. The trouble is that visible gets mistaken for important. Something ships and works; the metrics point at engineering, because engineering is where the metrics are. The decision about what to build left no dashboard behind, so it disappears from the account. Building got cheap, so the engineering numbers inflate. More ships, faster, and the charts look excellent while telling you almost nothing about whether the right things got built. So teams optimise what they can see, and end up with a well-instrumented machine building the wrong things efficiently. More engineering metrics will not fix this. Measure the other half. Every launch carries a verdict drawn from real numbers, landed, watch, or stalled, that updates as the numbers come in, and that one person is willing to be wrong about in public. That single move puts a scoreboard next to the decision, where there was none. Then attach a name. Every launch traces back to a call, and every call has one owner. When the verdict arrives, it belongs to the person who made the call. That is what makes judgment reviewable: a record of calls and how they read out. The read is only as strong as the numbers under it. One owned source of truth, audited, every number traceable to where it came from, turns "I think it landed" into something a room can act on. Agents pull the numbers and check the claims against their sources. A person delivers the verdict. None of this is as clean to measure as deploy frequency, and it should not be. Manage as though only the traceable things happened, and you will starve the part that mattered most while your charts go up and to the right. > end up with a well-instrumented machine building the wrong things efficiently ### 01. The CPTO is a consequence, not a trend Published: April 2026. Reading time: 2 min. Source: https://dacard.ai/paper-trail/the-cpto-is-a-consequence-not-a-trend Collapse product and engineering into one seat and you have not coined a title. You have revealed one. The CPTO, one person running both product and engineering, gets discussed like a fashion. That framing misses what it is. Nobody decided the CPTO should exist. The wall between product and engineering stopped making sense, and the title is the name we are putting on the rubble. That wall was load-bearing for a reason. Product decided what to build, engineering built it, and the handoff between them was expensive enough that you wanted a senior person owning each side. When building was slow, the split was the efficient move. Building got cheap, and the handoff mostly went with it. When one capable person can hold the product call and get close enough to the build to make it real, two senior leaders coordinating across a boundary becomes overhead. One person owning the line from what is worth building through to whether it landed is a CPTO, whether or not you use the title. The deeper collapse is between strategy and operations. Direction set quarterly and reviewed monthly cannot steer something moving at agent speed. The strategic call and the operational call are now the same call, made with the numbers in front of you. Split that across two executives and you have put the handoff back at the level where it costs the most. The pay follows. A CPTO seat that pays more than either seat it replaced is one person doing what recently took two, at a technical depth the product role never used to require, and carrying the read afterward. A real consolidation being priced, not a buzzword being inflated. Reading it as a trend leads you astray, because trends reverse and this will not. Cheap building dissolved the boundary, and if anything it deepens. The question for a company is whether its product leadership is still built around a wall the technology already removed. The CPTO is not coming. It is what is left after the wall came down. > It is what is left after the wall came down.